What Leaves Your Server When You Switch the AI On
Every AI feature in a business system is a data transfer decision wearing a friendly button. This is the complete inventory of what leaves our infrastructure when each one runs, where it goes, what stays behind, and how to answer the question your compliance officer is about to ask.
There is a question that decides whether a Kenyan organization can use AI features in its business system, and almost no vendor answers it directly: when I press that button, what exactly is sent, and to whom? Not "we take security seriously". Not "enterprise-grade encryption". The actual contents of the actual request.
The reason it matters is not squeamishness. Under the Data Protection Act, an organization holding personal data in Kenya is the controller of that data, and moving it outside the country is a transfer the controller is answerable for — whether the transfer was made by a person or by a helpful feature nobody read the description of. Your software vendor is the processor. Neither of us gets to be vague about it.
So here is the inventory, feature by feature. It is long and it is specific, which is the only useful way to write it.
The first thing to know: it is off by default
No AI feature in the product sends anything anywhere unless a language-model provider has been switched on at the deployment level, with a key. Three providers are supported — Groq, OpenRouter and Google Gemini — and each requires two separate things to be true before it will run: an explicit enable flag, and a present API key. Either missing and the provider is skipped.
When none is enabled, every AI feature behaves the same way: it returns unavailable and the interface hides or greys the control. Nothing is queued for later. Nothing is buffered. The absence of a provider is not a degraded mode, it is a full stop, and the rest of the system carries on exactly as it did.
Two consequences follow that people find surprising, and we would rather they hear them from us. The switch is per deployment, not per organization — if you are on a shared hosted deployment, whether AI is available is a decision made for that deployment, not by each organization on it. And the providers are all outside Kenya, so switching one on is a cross-border transfer decision, full stop. If that is unacceptable for your data, the right answer is a deployment with no provider enabled, not a feature you promise not to press.
An AI feature you have not enabled is not a risk you have accepted quietly. It is a request that never gets made.
Why the default matters more than the policy
The boundary, drawn honestly
What is computed here, and what is composed there
Stays on our infrastructure
All of it, always, whether AI is on or off.
- Every figure on every insight card — scores, counts, breach rates, forecasts, variance, ageing. All computed in our own code against your database.
- The anomaly and pricing radars, the smart alerts, the approvals hub, the SLA clocks and the risk ranking on the support hub — arithmetic, not inference.
- Every document, attachment, certificate, receipt and photograph you have ever uploaded. No file is ever sent to a provider, in any feature.
- Every credential, PIN, hash, token and API key.
- The forecast engine's velocity calculations and the vendor scorecards' performance arithmetic.
Crosses to a provider, when you use a feature
Text prompts only, one request at a time.
- A short prompt built for that one feature, described line by line in the table below.
- The provider's model composes prose or a small JSON object, and that reply comes back.
- Nothing is stored on their side by us — we send, we read the response, we discard the request.
- What the provider itself retains is governed by their terms, not ours. We cannot make a promise on their behalf and will not pretend to.
The shape of every crossing
- One HTTPS request, a roughly twelve-second timeout, no retry beyond walking to the next enabled provider.
- No batching, no nightly upload, no sync. There is no channel that pushes your data to a provider on a schedule.
- On failure, the feature returns nothing and the screen carries on. Failure is always silent to the provider and visible to you.
The single most important line above is the one about files. Several of these features are about documents — supplier certificates, ticket attachments — and none of them read the document. The providers configured here are text models with no vision capability, so a certificate's existence can be scored and its contents cannot be.
Feature by feature: the exact payload
This is the table to hand to whoever is asking. Each row is what is actually assembled in the prompt for that feature, taken from the code rather than from a description of it.
| Feature | What is sent | Personal data? | Triggered by |
|---|---|---|---|
| Public website assistant | The visitor's question, plus snippets from our own published articles, docs, pages and courses | Only whatever the visitor typed | A visitor asking |
| Support copilot — draft a reply | Ticket subject, priority, description and the whole comment thread including internal notes, each line tagged only as Agent or Requester | Yes — whatever is written in the thread | An agent pressing the button |
| Support copilot — summarise thread | The same payload as a drafted reply, internal notes included | Yes — same | An agent pressing the button |
| Support copilot — suggest triage | Subject, priority, description, public comments only, plus your own category and department names | Yes — the public thread | An agent pressing the button |
| Support queue narrative | Seven counters: open, unassigned, breaching, due soon, waiting, resolved this month, average satisfaction | No — numbers only | Opening the support AI hub |
| Module insight narratives | The module name, a one-line computed summary, bullet text where a module supplies it, and the current recommendation sentence — capped at thirty lines | Rarely — only if a bullet names someone | A queued job, after you open the page |
| Supplier application scoring | The typed application data and which required documents are present or missing | Yes — the supplier's submitted details | A reviewer running the evaluation |
| Workflow assistant — drafting a workflow from a sentence | Nothing. Your sentence is matched against built-in templates by keyword, on our servers | No | — |
| Workflow assistant — explain a failure | The workflow log message, truncated to 400 characters, its status, and our own heuristic guess at the cause | Only if a log message contains a name | An admin opening the explanation |
| Workflow assistant — draft a notification message | The intent sentence the admin typed, plus the list of placeholder names permitted | Only whatever the admin typed | An admin drafting a message |
Two rows worth reading twice
First: the drafted reply and the thread summary deliberately include your internal notes, because a draft written without the internal context repeats questions you have already answered among yourselves. That is a genuine trade-off and you should decide it knowingly — if your internal notes contain material you would not send anywhere, either do not use those two actions or change what goes in your notes. Second: the workflow assistant is mostly not a language model at all. Drafting a workflow from your sentence, suggesting templates, spotting automation opportunities and building a condition are all keyword and arithmetic logic that never leaves the server — only two of its actions, explaining a failure and drafting a message, optionally hand a short prompt to a provider and fall back to deterministic text when none is available. That distinction is described in full in the workflow assistant that is mostly not a model.
What a name in a prompt actually looks like
The insight narratives deserve a paragraph of their own, because they are the feature most likely to run without anyone pressing anything, and the honest answer about personal data in them is usually not, sometimes yes.
The narrative prompt is built by flattening a module's computed insight into lines of text: the area name, a one-line summary such as 14 open · 3 SLA breaches · CSAT 4.2/5, the bullet lines a module chooses to publish, and the current recommendation sentence. Labels and numbers, in other words. But some modules write bullets that name things — a top overdue account, a supplier with a cost spike — and where a bullet names a party, that name goes in the prompt. There is no scrubbing step.
Where personal data can and cannot appear in an AI request
Never
Uploaded files of any kind, credentials, PINs, hashed passwords, tokens, payment card data, full table dumps, and anything at all when no provider is enabled. There is no code path that sends these.
Only if you press a button
Ticket threads, including internal notes, when an agent asks for a draft or a summary. Supplier application details, when a reviewer runs an evaluation. These never happen in the background.
Possible, in a background job
A module insight bullet that names a customer or supplier will carry that name into the narrative prompt, generated on a queue after somebody opens the page. Whether this happens depends on which modules you use and what their bullets say.
Not built: a redaction layer
There is no scrubbing or pseudonymisation step between our data and a prompt, and no per-feature switch that lets you enable a drafted reply while disabling narratives. It is all providers on, or all providers off.
If you want narratives without any possibility of a name crossing the boundary, the honest answer today is to leave the providers off and keep the computed cards, which are the substance anyway. The narrative is a paragraph restating them.
How to decide, in the right order
-
Establish who your data controller is, on paper
It is your organization, not your software vendor. That single sentence settles who has to make this decision and who has to be able to explain it later. Start there and the rest is straightforward.
-
Decide the transfer question before the feature question
Is a cross-border transfer of the categories of personal data in the table above acceptable for your organization, given who your data subjects are? For a school holding minors' records, a clinic, or an NGO with beneficiary data, the honest answer is often no — and that is a complete answer, not a failure.
-
If yes, read the terms of the specific provider you will enable
Not "LLM providers" in general. Groq, OpenRouter and Gemini have different retention and training terms, and OpenRouter is a gateway that routes onward to further models, which is a second hop you must account for. This is the step people skip.
-
Write down which features your team may use
Because there is no per-feature switch, the control is procedural. "Drafted replies yes, thread summaries yes, supplier evaluation no" is enforceable through training and review, not through configuration, and it should be written down either way.
-
Change what goes in your internal notes
This is the cheapest control on the list and the one with the most effect. If drafted replies are in use, your internal notes are now part of an outbound payload — so notes carry facts and actions, and never a credential, an ID number or a judgement about a person.
-
Record the decision where an auditor will find it
One page: which providers are enabled, which features are permitted, what categories of data can cross, who approved it and when. This is the document that turns "we use AI" from an exposure into a controlled process.
Questions to put to any vendor, including us
Score the answers, not the enthusiasm
Every one of these has a factual answer. A vendor who cannot give it either does not know what their own product sends, or would rather you did not.
Name the providers, and tell me where they run
Make them prove it: Ask for the specific companies and regions, not "leading AI providers". Then ask which one handles a request first and what happens when it fails.
Show me the prompt
Make them prove it: Ask them to print the exact text of an outbound request for one feature, with a sample record in it. This is the question that separates a vendor who has read their own code from one who has read their own marketing.
Which features send documents?
Make them prove it: If any feature claims to read an uploaded certificate, invoice or ID, it is sending the file or its extracted text somewhere. Ask which, and to whom, and whether extraction happens on their infrastructure or a third party's.
What runs without a human pressing anything?
Make them prove it: Background summarisation, nightly enrichment and "smart" indexing are the ones that surprise people. Ask for the list of scheduled jobs that contact a provider.
Can I turn AI off and keep the analytics?
Make them prove it: A good architecture computes the numbers itself and uses the model only for prose. If disabling AI empties the dashboards, the numbers were never yours.
Are prompts written to your application logs?
Make them prove it: Ask directly. Logs get shipped, backed up and read by support staff, and a prompt in a log is a copy of the data you were worried about in a place nobody assessed.
Our own answer to the last one, for completeness: prompts are not logged. A failed request logs the provider name, the HTTP status and the provider's error body — which in some providers' error formats can echo a fragment of what was sent. That is a narrow and real exception and we would rather state it than claim a clean sheet.
What we do and do not do
What AWRA OpsHub does today
- Off by default: no provider enabled means no request is ever made, and every AI surface degrades to hidden rather than queued.
- Every number computed on our own infrastructure, in our own code, against your database — scores, forecasts, breach rates, radars, rankings. The model writes prose about them, it does not produce them.
- No file, ever: no attachment, certificate, receipt, photograph or document is sent to any provider by any feature.
- Copilot actions are strictly agent-initiated — a drafted reply, a summary or a triage suggestion happens because somebody pressed a button.
- Suggest-only behaviour: no AI output writes to a record anywhere. A triage suggestion is validated against your own category and department lists and still has to be saved by a human.
- Fail-soft everywhere: a missing provider, a timeout, a rate limit or unparseable output all produce "unavailable" rather than an error or a retry storm.
- Prompts are not written to our application logs.
What it does not do
- No per-organization AI switch. Providers are enabled per deployment. On a shared deployment, availability is not each organization's own decision.
- No per-feature switch. You cannot enable drafted replies while disabling insight narratives. It is all on or all off.
- No redaction or pseudonymisation layer between your data and a prompt. Where a computed bullet names a party, that name goes in the prompt.
- No Kenyan or regional provider option. All three supported providers are outside Kenya, so enabling one is a cross-border transfer.
- No self-hosted model option. There is no configuration that points these features at a model running on your own hardware.
- No audit log of AI requests. There is no per-organization record of which features were used, when, on which records — so you cannot reconstruct after the fact what crossed the boundary.
- No promise about what a provider retains or trains on. That is governed by their terms, which you should read for the specific provider you enable.
The two gaps that matter most for Kenyan compliance are the missing per-organization switch and the missing request log — the first because it makes the decision somebody else's, the second because it makes the decision unauditable. A self-hosted or regional provider option is the structural answer for organizations that cannot transfer at all, and it is the request we would most like to hear if that describes you.
Our take
Turn the AI on if you have decided the transfer is acceptable for your data, and leave it off if you have not — but make it a decision, on one page, with the provider named. The good news is the part nobody markets: the analytics are not the AI. Every score, forecast, breach count and radar in this product is computed in our own code and works identically with every provider switched off. What you lose without a provider is a paragraph of prose restating numbers you can already read, a reply you would have edited anyway, and a triage suggestion you were going to check. That is a genuinely small price, and it is the reason we are comfortable telling you exactly what the alternative sends.
Read alongside this: what an in-app AI assistant can and cannot answer covers why the site assistant does not read your data at all, numbers first, words second explains the computed-then-narrated architecture, the support copilot covers the ticket features in detail, and the Data Protection Act and business systems covers the wider duties this sits inside.
Analytics that work with the AI switched off
Every score, forecast and radar computed in our own code against your data. The language model writes prose about the numbers — it never produces them, and it never sees a file.
See Intelligence InsightsFrequently asked questions
If we do not enable a provider, do the AI pages stop working?
The numbers all keep working; only the prose disappears. Insight cards, scores, forecasts, breach counts, anomaly radars, smart alerts and the support risk ranking are computed in our own code against your database and do not involve a model at all. What you lose is the two-to-four-sentence narrative on top of each card, the drafted reply, the thread summary, the triage suggestion and the supplier evaluation. Each of those surfaces simply hides or reports itself unavailable. Nothing is queued for when a provider appears.
Are our uploaded documents sent to the AI?
No — not by any feature, ever. There is no code path that sends a file, and the providers configured here are text-only models with no vision capability, which is why the supplier evaluation scores whether a required certificate is **present** and cannot say anything about what it contains. If a vendor tells you their AI reads your uploaded certificates, ask them which service extracts the text and where that service runs, because a second processor has just entered your assessment.
Do our internal ticket notes get sent anywhere?
Yes, if an agent uses the drafted-reply or summarise action on that ticket. Both deliberately include internal notes, because a draft written blind to the internal context repeats questions you have already answered internally. The triage suggestion does not include them. Nothing is sent in the background — an agent has to press the button — and nothing is sent at all if no provider is enabled. If your notes contain material you would not transfer, either restrict those two actions by policy or change what goes in the notes. We think the second is the better habit anyway.
Can we enable AI for one department and not another?
No. Provider enablement is a deployment-level setting, and there is no per-organization, per-department or per-feature switch on top of it. The control available today is procedural: decide which features your team may use, write it down, and train to it. We recognise this is weaker than a configuration switch, and a per-organization toggle is the gap we would close first for compliance-sensitive customers.
Which provider handles our request, and can we choose?
Three are supported — Groq, OpenRouter and Google Gemini — and they are tried in a configured order, the first enabled one with a working key winning. The order is set on the deployment, so it is choosable, but not by each organization. One nuance worth carrying into your assessment: OpenRouter is a gateway that routes onward to other providers' models, so enabling it introduces a second hop with its own terms. If you are documenting a transfer, name the provider **and** whatever it routes to.
Does this satisfy the Data Protection Act?
We cannot answer that for you, and any vendor who says they can is selling you something. What we can do is make the assessment possible: your organization is the data controller, we are the processor, the providers are outside Kenya, and the table in this article tells you exactly which categories of data cross the border in which feature. Whether that transfer is lawful and appropriate for your data subjects is a decision for your organization, ideally recorded on a page naming the provider, the permitted features and the approver. If the answer is that no transfer is acceptable, leave the providers off — the analytics are unaffected.
Can we run the model on our own server instead?
Not today. There is no configuration that points these features at a model on your own hardware, and no regional provider option. For organizations that genuinely cannot transfer personal data — some clinics, schools and NGOs are in that position by policy rather than by preference — the honest position is that our AI features are not for you, and the rest of the product is entirely unaffected. If a self-hosted option would change that, tell us, because it is the request that would carry the most weight.
