AI projects tend to follow a recurring sequence. A pilot runs, the results are good, a presentation is made. After the presentation, someone from information security or legal asks a question: where is this data being processed?
When the answer is "on a service abroad", the project usually goes back to the start. What is lost is not only time. The pilot results lose validity too, because the architecture changes.
The deployment model decision therefore belongs at the beginning of a project rather than the end, and it is not one an engineering team makes alone.
Three models, three distributions of responsibility
Three deployment models are in practical use, and the difference between them is not only where the server sits but who operates what.
Global SaaS. The platform runs on cloud and GPU resources abroad. It is the fastest to deploy, scales on demand, and puts no infrastructure operating burden on the customer.
Local SaaS. Data is processed and stored inside the country. The service provider operates the infrastructure; the customer only consumes it. The cross-border transfer question disappears without creating an operating burden internally.
On-premise. The platform runs entirely in the customer's own data centre on its own hardware. Data never leaves the corporate network. In exchange, patch management, monitoring, backup and capacity planning move to the customer.
A side-by-side comparison sits in the deployment section of our product pages. What follows focuses on the inputs to the decision.
The legal framework changed in 2024, and so did the decision logic
A sentence heard often in deployment discussions is "we will take explicit consent and it is settled". Since 1 June 2024 that is less true than it was.
Article 9 of Turkish Law No. 6698, which governs transfers abroad, was amended by Law No. 7499, effective 1 June 2024. The new structure moves from a consent-centred approach to a tiered one: an adequacy decision first, appropriate safeguards where none exists, and exceptional circumstances only after that (kvkk.gov.tr).
The critical point sits in the third tier. The exceptional grounds, including explicit consent given after the person has been informed of the risks, apply only to incidental transfers. In other words, for regular, continuous and recurring transfers, relying on explicit consent is not the intended mechanism.
For voicebot and chatbot projects the implication is direct: sending thousands of conversations abroad daily for analysis is by definition a regular, continuous transfer. That flow needs an appropriate safeguard. Standard contractual clauses are one such method, and a signed contract must be notified to the Authority within five business days. Binding corporate rules are used for transfers within a corporate group.
The question in the decision meeting is therefore not "can we obtain consent" but "which safeguard mechanism will we put in place and who will maintain it".
Do you actually know which data leaves
Deployment discussions circle the question of whether data leaves the country, but which data rarely gets separated out. In a voicebot flow, quite different categories of data are in motion:
- Raw audio recordings
- Transcripts
- Summaries and labels derived from the text
- Customer identity and account data
- System logs and metrics
There is no requirement that all of these be processed in the same place. Masking identifiers and analysing only the text, or stripping sensitive fields and processing the remainder, are viable designs. Data minimisation of this kind can make it legally defensible to run some workloads on more flexible models.
One caution: masking that is not built carefully gives a false sense of security. If a customer says their name, address and order number aloud during a call, masking database fields is not enough; personal data inside the text itself has to be handled too. That process needs to be measured, not assumed.
Two technical factors that drive the decision
Latency
Processing on a resource abroad adds a network round trip. On text channels the difference usually goes unnoticed. On the voice channel it lands directly on conversation quality, because the budget there is already tight. We cover this in the latency budget article.
The practical consequence: for voice workloads there is a performance argument for in-country resources that is independent of compliance. For text workloads that argument is much weaker.
Operating burden
The cost of an on-premise deployment does not end with hardware. The customer takes on capacity planning, version upgrades, security patching, monitoring and alerting, backup and disaster recovery, and incident response.
Without a team and process to run those, a closed-network system can end up more exposed than a managed one. "It is secure because it is in our data centre" does not hold for an unpatched component.
So the question to ask is not "which is more secure" but "which security responsibility will which team carry".
You do not have to pick one model
Most organisations treat this as a single choice. In reality workloads sit at very different sensitivity levels.
A distribution we see frequently: the chatbot answering public product questions runs in a managed deployment, because the data it handles is already public. The HR assistant and the internal policy assistant run inside the corporate network, because employee data and internal documents should not leave.
Making that split is both cheaper and faster than building everything to the strictest requirement. Deciding the deployment model per workload is a better approach than deciding it per organisation.
Lock-in and the exit plan
The ability to move between models is a contract-stage question. Asked later, you have no negotiating position.
Points to settle:
- In what format can the knowledge base, indexes and conversation records be exported
- Are flow and scenario definitions portable, or embedded in the platform
- When the model changes, can you compare against your existing evaluation set
- How is deletion of data at end of contract evidenced
The fourth matters under data protection law as well; how the deletion obligation will be discharged should be written into the contract.
Steps in the decision process
The sequence that works with the organisations we run this with:
- Define the workload: which data, at what volume, at what frequency
- Separate the data types: which of them genuinely has to leave
- If there is a transfer, identify which tier you are on (adequacy decision, appropriate safeguard, exceptional ground)
- Establish whether the transfer is regular or incidental
- Measure the latency requirement rather than assuming it
- Write down which team carries the operating burden
- Put exit and data portability terms into the contract
- Document the decision together with its rationale
That last step is what matters at audit. When someone asks a year later why it was built this way, there needs to be a record of who decided and on what grounds. AI management system standards such as ISO/IEC 42001 look for exactly this kind of record (iso.org).
To work through the deployment models and the decision tree against your own scenario, see the deployment sections on the Voicebot Platform, Chatbot Platform and API Platform pages.
This article is general information and is not legal advice. Review your own case with your legal team before implementation.
References
- Turkish Data Protection Authority, transfers abroad. kvkk.gov.tr
- Turkish Data Protection Authority, Guide on Transfer of Personal Data Abroad (Publication No. 48). kvkk.gov.tr
- Turkish Data Protection Authority, standard contract notification module announcement. kvkk.gov.tr
- ISO/IEC 42001:2023, AI management system. iso.org