Privacy Policy
How FourMat collects, uses, protects, pseudonymizes, and deletes personal data — on this website, in the AI agents we build, and across the messaging platforms those agents run on.
1. Who we are
FourMat ("FourMat", "we", "us") is an AI-agent and workflow-automation studio registered in Bosnia and Herzegovina. We design, build, and operate AI assistants and automation systems for small and medium businesses.
| Legal entity | FourMat |
| Registered address | Barska 59F, 71210 Sarajevo, Bosnia and Herzegovina |
| Contact for privacy matters | info@fourmat.dev |
| Website | https://fourmat.dev |
Sinkronik is our platform — the software our AI agents run on, and the name under which our applications are registered with platform providers including Meta. Sinkronik is a product and brand of FourMat, not a separate company. Every reference to Sinkronik in this policy means software operated by FourMat, and FourMat is the entity accountable for it.
This policy covers three distinct things: our marketing website at fourmat.dev, the consultation and sales process, and the AI agents and automations we build and host for our business clients.
2. Our two roles: controller and processor
Which data-protection role we hold depends on whose data is being processed. The distinction matters, because it determines who you contact to exercise your rights.
| Situation | Our role | Who decides the purpose |
|---|---|---|
| You visit fourmat.dev, email us, or book a consultation call | Controller | FourMat |
| You message a business that uses an AI agent we built (on WhatsApp, Messenger, Instagram, or a website chat widget) | Processor | That business (our client) is the controller |
| We operate, monitor, secure, and debug the platform itself | Controller, for security and service-integrity purposes only | FourMat |
When we act as a processor, we handle personal data only on the documented instructions of the client business, under a written data-processing agreement. We do not decide what the agent is used for, we do not repurpose the data for our own ends, and we do not use it to build products for anyone else.
3. Data we collect on this website
Our website is deliberately minimal. It is a statically generated site with no user accounts, no logins, and no behavioural tracking.
- No cookies are set by this website. There is no cookie banner because there is nothing to consent to.
- No third-party analytics, advertising pixels, session recorders, or social tracking scripts run on this site. We do not use Google Analytics, and we run no Meta Pixel or Conversions API on fourmat.dev.
- Fonts are self-hosted from our own domain. Your browser makes no request to Google Fonts or any other third-party font service when you load a page.
- Our web server keeps standard access logs (IP address, timestamp, requested URL, user agent, response status) for security, abuse prevention, and troubleshooting. These are retained for a maximum of 30 days and are never used to profile you or build a marketing audience.
If you contact us by email or book a consultation call, we process the details you choose to give us — typically your name, email address, phone number, company, and whatever you tell us about your business problem. We use these to answer you, prepare the call, and, if you become a client, to deliver the work and issue invoices.
4. Data processed by the AI agents we build
When a business deploys one of our AI agents, our platform processes the conversations and business records needed to make the agent work. Depending on which channels and features that business has enabled, this can include:
- Message content — what an end customer writes to the business and what the agent replies.
- Channel identifiers — a WhatsApp phone number, a Messenger page-scoped ID (PSID), an Instagram-scoped ID (IGSID), or an anonymous visitor ID generated by a website chat widget.
- Profile information the messaging platform makes available, such as a display name.
- Media metadata — the type, size, and identifiers of an image, document, audio, or video message. We do not download or store the media content itself on the first-release channels.
- Delivery and lifecycle data — sent, delivered, read, and failed receipts, timestamps, retry counts, and provider message identifiers. This is stored in a transport ledger that references, but does not duplicate, the message content.
- Contact and lead records created by the business in its CRM — name, email address, phone number, source, status, and notes.
- Booking and appointment details, where calendar booking is enabled — requested service, time slot, and the contact details needed to confirm it.
- Quote and pricing data, where automated quoting is enabled — the inputs the customer supplied and the quote produced.
- Knowledge-base content the business uploads so the agent can answer accurately — its own documents, FAQs, price lists, and policies.
We do not ask for, and our agents are not designed to solicit, special-category data such as health, biometric, religious, or political information. Where a client operates in a sector where a customer may volunteer sensitive information anyway — a clinic, for example — the pseudonymization described in section 5 applies before any of it reaches an external model, and the client's data-processing agreement sets out the additional safeguards.
5. Pseudonymization and anonymization before any LLM sees the data
This is the part of our architecture we consider non-negotiable, and it is the reason our clients can use large language models in regulated and privacy-sensitive settings.
Before a message is sent to any external large language model provider, it passes through a privacy preprocessor that runs inside our own infrastructure. The preprocessor detects direct and indirect identifiers and replaces each one with a neutral, deterministic placeholder. The model therefore receives the structure and intent of a message without the identifying values inside it.
| Detected in the message | What the model actually receives |
|---|---|
| Email addresses | EMAIL_1, EMAIL_2, … |
| Phone numbers | PHONE_1, PHONE_2, … |
| Dates | DATE_1, DATE_2, … |
| Times | TIME_1, TIME_2, … |
Placeholders are sequential and carry no derivable relationship to the original value — they are not hashes, encodings, or reversible transformations of it. There is no key inside the prompt that could be used to reconstruct the identifier, so the text leaving our infrastructure cannot be re-identified by the model provider or by anyone who obtained the prompt.
The mapping back to the real values never leaves our systems. Re-identification happens only inside our infrastructure, only where the business function requires it — writing a confirmed booking into a calendar, saving a lead into the CRM, or sending the reply back through the messaging channel — and only for the business that owns the conversation.
- Pseudonymization is applied to the incoming message and to every earlier turn of the conversation that is replayed as context, so an identifier cannot leak through conversation history.
- Pseudonymization is applied before retrieval as well as before generation, so a customer's details are not used as a raw search key against a knowledge base.
- The privacy mode is configurable per business (off, basic, or strict) and defaults to on. A business must make a deliberate, recorded decision to disable it, and we advise against it for any deployment touching customer or patient data.
- Operational and analytics logging is metadata-only. Message bodies, recipient addresses, credentials, and access tokens are never written to our analytics store. Error messages are truncated and scrubbed before they are recorded.
Aggregate quality and usage reporting is derived from anonymized counters — message volumes, latency, token usage, resolution and handoff rates — that contain no personal data and cannot be traced back to an individual conversation.
6. Meta platforms: WhatsApp, Messenger, and Instagram
FourMat is an approved Meta Tech Provider. Our Sinkronik application connects business clients to the WhatsApp Business Platform (Cloud API), Messenger Platform, and Instagram Messaging so their AI agent can answer customers on the channel the customer already uses. This section describes how we handle Platform Data and applies in addition to everything else in this policy.
We access Platform Data only with the explicit authorization of the business that owns the WhatsApp Business Account, Facebook Page, or Instagram Professional account, and only through permissions that business has granted. We request the narrowest permission set that makes the integration work — messaging and the account management needed to subscribe to webhooks — and nothing beyond it.
Our commitments regarding Meta Platform Data:
- We use Platform Data solely to provide the messaging service the business asked us to operate on its behalf. We do not repurpose it.
- We do not sell, license, rent, or otherwise transfer Platform Data to any third party, and we do not share it with data brokers, information-resellers, or advertising networks.
- We do not use Platform Data for advertising, ad targeting, audience building, look-alike modelling, credit or eligibility decisions, or any surveillance purpose.
- We do not use Platform Data to train, fine-tune, or evaluate machine-learning models.
- We transfer Platform Data to service providers only where it is necessary to deliver the service, under written contracts imposing equivalent obligations. Section 8 lists every category of provider we use.
- We keep Platform Data only as long as it is needed to provide the service, and we delete it on request, on deauthorization, or on termination — see sections 9 and 12.
- We keep each business's data strictly separated from every other business's. Tenant isolation is enforced in the data layer itself, on every read and every write, including the vector store and the analytics store.
- We comply with the Meta Platform Terms and Developer Policies, including the WhatsApp Business Messaging Policy and Commerce Policy, and we notify Meta and affected businesses of any incident affecting Platform Data as required.
Message delivery rules imposed by Meta are enforced by our server, not by the AI model. Free-form replies are only sent inside the 24-hour customer service window; outside it, only message templates that the business has had approved by Meta can be sent. The model is never permitted to decide whether a message may legally be delivered.
Every inbound webhook from Meta is cryptographically verified against the application secret before its contents are parsed, and the resolved account identifiers must match the business the channel belongs to. Access tokens, application secrets, and verification tokens are stored encrypted, are write-only from the administrative interface, and are never written to logs or transport records.
Your conversation on WhatsApp, Messenger, or Instagram is also subject to Meta's own privacy policy for the platform you are using. Meta's processing as the platform operator is outside our control and is governed by its own terms.
7. Legal bases for processing
Where the GDPR applies, we rely on the following legal bases. Where we act as a processor, the client business is responsible for establishing the legal basis for its own processing, and we support it in doing so.
| Processing | Legal basis |
|---|---|
| Answering your enquiry, running a consultation call, delivering a project, invoicing | Performance of a contract, or steps taken at your request before entering one (Art. 6(1)(b)) |
| Operating an AI agent on behalf of a client business | The client's legal basis — normally contract or legitimate interests — with FourMat processing on its instructions (Art. 28) |
| Server logs, abuse prevention, securing the platform, fraud and incident response | Legitimate interests in keeping the service available and secure (Art. 6(1)(f)) |
| Marketing emails, where we ever send them | Consent (Art. 6(1)(a)), withdrawable at any time |
| Keeping accounting and tax records | Legal obligation (Art. 6(1)(c)) |
We also process personal data in accordance with the Law on Protection of Personal Data of Bosnia and Herzegovina, which applies to us as a locally established company.
8. Service providers and sub-processors
We keep our supply chain deliberately short. The following categories of provider may process personal data on our behalf, each under a written contract that restricts them to our instructions. Which of them apply to a given deployment depends on the channels and features that business has enabled; the exact, named list for a client is maintained in its data-processing agreement and the client is notified before any addition.
| Category | Purpose | What they receive |
|---|---|---|
| Large language model providers (OpenAI, Anthropic) | Generating the agent's replies and embeddings for knowledge retrieval | Pseudonymized message text and business knowledge-base content only — never raw identifiers, and never under terms permitting model training |
| Messaging platforms (Meta — WhatsApp, Messenger, Instagram) | Delivering and receiving messages on the customer's chosen channel | Message content and the platform's own channel identifiers, as inherent to sending a message |
| Messaging providers (Twilio, Infobip) | Alternative WhatsApp delivery routes where a business uses one | Message content and the recipient phone number, as inherent to delivery |
| Calendar providers (Google Calendar) | Writing confirmed appointments into the business's calendar, where booking is enabled | The appointment details and the contact information needed to identify the booking |
| Hosting and infrastructure providers | Running our servers, databases, vector store, and analytics store | Data at rest and in transit, encrypted, with no access to application-level content in the ordinary course |
| Email delivery | Transactional email — confirmations, notifications, and our replies to you | Recipient address and message content |
Our vector store and analytics database are self-hosted on our own infrastructure rather than rented as third-party SaaS, which keeps retrieval data and operational telemetry inside our perimeter.
9. How long we keep data
Retention is enforced automatically by scheduled deletion jobs, not left to manual housekeeping. The platform defaults are below; a client business can shorten any of them for its own deployment, and several clients do.
| Data | Default retention |
|---|---|
| Conversations and message content | 365 days |
| Automation runs and tool executions | 180 days |
| Channel transport records (delivery ledger) | 90 days |
| Operational and analytics telemetry (metadata only) | 180 days, capped by a six-month store-level expiry |
| CRM contacts and leads | Retained until the business sets a window or deletes them, because these are the business's own customer records |
| Website server access logs | 30 days |
| Contracts, invoices, and accounting records | As required by tax and company law |
Deletion is permanent and runs across every store that holds the data — the primary database, the vector store, and the analytics store — not just the one a user can see. Audit records of a deletion keep only a hashed reference, a status, and counts; they contain no personal data.
10. How we protect data
- All data in transit is encrypted with TLS. Credentials, access tokens, and application secrets are encrypted at rest and are write-only from the administrative interface — they cannot be read back, only replaced.
- Multi-tenant separation is a hard architectural invariant. Every query is scoped to a single business at the data layer, including deletions and vector-store operations, so one client's data cannot be reached from another client's context.
- Every inbound platform webhook is authenticated — HMAC signature verification over the exact raw request body — before the payload is parsed, and request bodies are size-capped.
- Secrets, signatures, cookies, raw headers, and unredacted webhook bodies are never written to logs or transport records. A redactor strips secret fields, message bodies, IP addresses, user agents, and contact fields, and bounds nesting and length.
- Administrative access is role-based and least-privilege, authenticated with short-lived tokens.
- Duplicate and replayed messages are detected and discarded idempotently, so a replayed webhook cannot cause a second action.
- Our own team is small and entirely in-house. We do not outsource development, and no subcontractor is given access to client production data.
No system is perfect. If a personal-data breach occurs, we will notify the affected client businesses without undue delay so they can meet their own 72-hour notification duty, notify the competent supervisory authority and affected individuals where the law requires it, and notify Meta where Platform Data is involved.
11. Your rights
Subject to the applicable law, you have the right to:
- Access the personal data we hold about you, and receive a copy of it.
- Have inaccurate data corrected.
- Have your data erased — see section 12 for how.
- Restrict or object to processing, including processing based on legitimate interests.
- Receive your data in a portable, machine-readable format.
- Withdraw consent at any time, where processing is based on consent, without affecting the lawfulness of what came before.
- Lodge a complaint with a supervisory authority — the Personal Data Protection Agency of Bosnia and Herzegovina, or the authority in your country of residence if you are in the EU or EEA.
Write to info@fourmat.dev to exercise any of these. We answer within 30 days. Where we are only the processor, we forward your request to the client business that controls the data and assist it in responding, and we tell you that we have done so.
Our AI agents do not make decisions producing legal or similarly significant effects about you without human involvement. An agent qualifies leads, books appointments, answers questions, and prepares quotes; a person at the business makes the decisions that matter. You can ask to speak to a human at any point in a conversation, and the agent will hand the conversation over.
12. Data deletion
This section is our data deletion instructions, including for data obtained through Meta platforms.
If you are an end customer who messaged a business on WhatsApp, Messenger, Instagram, or a website chat widget:
- Email info@fourmat.dev with the subject line "Data deletion request".
- Tell us the business you were talking to and the channel you used, and give us the identifier you used — your WhatsApp phone number, or the Instagram or Facebook account name you messaged from. We need it to locate your conversation and nothing else.
- We verify the request, delete your conversation history, message records, transport records, derived retrieval data, and any contact or lead record created from that conversation, and we ask the client business to delete anything it exported into its own systems.
- We confirm completion by email within 30 days. Deletion is permanent and runs across every store — the primary database, the vector store, and the analytics store.
You can also revoke our application's access at any time from the platform itself — in Facebook or Instagram settings, under Business Integrations or Apps and Websites. Revoking access stops all further processing immediately. It does not by itself delete what was already received, so send the email as well if you want erasure.
If you are a client business: ask us and we will run a full tenant erasure, which permanently removes every record belonging to you across all stores in a verified order, or a full export of your data first if you want to take it with you. Erasure is irreversible, requires explicit confirmation, and is audited without storing any personal data in the audit record.
We may retain the minimum necessary to meet a legal obligation — an invoice required by tax law, for example — and we will tell you if that applies.
13. International transfers
FourMat is established in Bosnia and Herzegovina, which is outside the European Economic Area. Where we process personal data originating in the EU or EEA, we do so under appropriate safeguards — Standard Contractual Clauses with the client business, supplemented by the technical measures described in this policy, of which the pseudonymization in section 5 is the most significant.
Some of our service providers — model providers in particular — may process data in the United States. Those transfers are made under Standard Contractual Clauses or an equivalent transfer mechanism, and the data they receive is pseudonymized before it leaves our infrastructure.
A client with a data-residency requirement should raise it during scoping. Hosting region and provider selection are part of what we design, not a fixed constraint.
14. Children
Our services are sold to businesses and are not directed at children. We do not knowingly collect personal data from anyone under 16. If you believe a child has sent data to an agent we operate, write to info@fourmat.dev and we will delete it.
15. Changes to this policy
We update this policy when the product, our providers, or the law changes. The revision date at the top of this page always reflects the current version. Where a change materially affects how we handle personal data, we notify client businesses directly before it takes effect.
16. Contact
Questions about this policy, a request to exercise your rights, or a data deletion request — all go to the same place, and a human answers.
| info@fourmat.dev | |
| Post | FourMat, Barska 59F, 71210 Sarajevo, Bosnia and Herzegovina |