Legal
AI Governance
What the AI does, what it will never do, who releases, what is recorded, and where responsibility sits when output informs a decision about a person.
What this document is
This is the statement of how KRAGOS uses artificial intelligence, what it will and will not let a model do, and where responsibility sits. It is written to be read by a customer's board, its auditor and its regulator, not only by its IT team.
It is incorporated into the Terms of Service by clause 1.9 of those Terms. Where it says we will or we do not, that is an undertaking, not a marketing line.
1. Scope
This statement covers every use of artificial intelligence in the KRAGOS products and on the KRAGOS surfaces: STEMPA, MakTy, HELM, Pulse, the assistant on kragos.ai, the free compliance calendar, the document rail and the voice rail.
It is published by Ecopackaging (Pty) Ltd, registration number 2014/032538/07, trading as KRAGOS, of 750 Nieuwhout Street, Garsfontein, Pretoria, 0081, South Africa.
2. What the AI does
In the KRAGOS products, artificial intelligence is used to:
- read a document and extract structured fields from it, for example an invoice, a vendor pack, a bank statement or a contract;
- classify an item into a category, for example a transaction into a ledger account or an enquiry into an intent;
- draft text, for example a letter, a message, a minute, a filing narrative or a campaign;
- summarise a set of records into a briefing;
- match records to each other, for example a payment to an invoice;
- detect that something looks wrong, for example a missing filing, an unusual amount or a supplier whose compliance has lapsed;
- answer a question about how the system works, in the assistant;
- propose an act, and present it for release, which is the whole point of the architecture.
Every one of those outputs is a proposal. It is presented with what it would do, and it waits.
3. What the AI does not do
It does not act. It does not pay, transfer, send, publish, sign, file, submit, delete or commit anything on its own.
It does not decide who in your business has authority. Authority is set by you and enforced by the system.
It does not change its own bounds, raise its own limits, or grant itself a permission.
It does not give legal, tax, accounting, audit, actuarial, financial or medical advice, and its output must not be treated as such.
It is not trained on your data. Clause 8 says so operatively.
It does not run without a record. Clause 6 describes the record.
4. The named capabilities
| Product | What the AI does in it | What still needs a human release |
|---|---|---|
| STEMPA | Reads the authority register and the bounds, and checks a proposed act against them. Proposes the act and the record of it. | Every act. STEMPA is the release gate itself. |
| MakTy | Reads registers and statutory documents, extracts dates and obligations, detects a missing or late filing, and drafts the filing narrative. | Any submission to a regulator, any message to a supplier, any change to a register of record. |
| HELM | Extracts and classifies finance, asset, people, project and funding records. Matches payments to invoices. Drafts reports and board packs. | Any payment, any journal that changes the ledger of record, any outbound message, any document issued in the customer's name. |
| Pulse | Drafts campaigns, content, social posts and outbound messages on approved templates. Proposes a schedule. | Every send and every publish. |
| The assistant on kragos.ai | Answers questions about KRAGOS and routes you to a booking, a written enquiry, or the free compliance calendar. | Nothing is committed by it. It cannot reach into a customer tenant. |
| The free compliance calendar | Produces a calendar of statutory dates and obligations from what you tell it about your business. | It is information only. Clause 12 of the Terms of Service and the notice on the tool itself apply. |
5. Human release: the rule
Anything that spends, sends, signs or files needs a person
Spends. A payment, a transfer, a purchase, a commitment of budget.
Sends. An email, a WhatsApp message, an SMS, a campaign, a publication, a notice.
Signs. A contract, an authorisation, a mandate, an approval carrying legal effect.
Files. A statutory return, a regulatory submission, a filing with a public body.
None of these happens without a named natural person, holding release authority for that class of act, releasing it within the bounds recorded against their seat.
The release is performed by a person, not by a role, not by a service account and not by a rule.
The person releasing sees what the act will do before they release it.
The person releasing may refuse, may amend, and may escalate. Refusal is recorded as an outcome in its own right.
Where a customer configures a standing or scheduled instruction, the authorisation of that standing instruction is itself a release, is recorded as one, and names the person who gave it. Clause 9.4 of the Terms of Service governs this.
There is no mode, setting or feature that removes the release gate.
6. STEMPA as the record
Every released act is written to the STEMPA journal. The journal is append only: entries are not editable and are not deletable through the product.
Each entry records:
| Field | What it is |
|---|---|
| Authority | Who released the act, against which seat, and what release authority that seat held at that moment. |
| Bounds | The limits in force on that seat at that moment: spend limit, permitted recipients, permitted documents, permitted systems. |
| Act | What was proposed and what was released, including the model output relied on and the inputs that produced it. |
| Outcome | What actually happened, including a failure, a rejection by a third party system, or a refusal by the releasing person. |
| Re-executable | Enough of the inputs and the configuration to run the act again and see whether the same thing happens. |
The customer may read and export the journal at any time during the term, and during the export window in clause 20.2 of the Terms of Service.
The journal is the evidence. If an act is disputed, the journal is what is examined.
7. Model providers
We name our model providers rather than describing them generically.
| Provider | What it does | Where |
|---|---|---|
| Anthropic PBC | Large language model inference. This is the primary model provider for the reasoning, extraction, classification and drafting capabilities. | United States |
| ElevenLabs | Voice synthesis for the voice rail. It converts released text to speech. | United States |
The sub-processor schedule in clause 19 of the Privacy Notice lists these and every other service we depend on, with what data reaches each.
If we add or change a model provider we will update this statement and the Privacy Notice before the change goes live, and clause 18.5 of the Terms of Service gives customers notice and a right to object.
We do not train our own foundation models.
8. No customer data trains any model
The undertaking
We do not use, and we do not permit any model provider to use, customer data, customer content, prompts containing customer data, or output derived from them, to train, fine tune, evaluate for training purposes, or otherwise improve any artificial intelligence model, whether ours or anyone else's.
This is clause 8.5 of the Terms of Service. It survives termination.
Prompt content is sent to a model provider for inference and for no other purpose.
We configure our provider accounts so that provider-side training on our traffic is off and retention is limited to what the provider needs to run the request and to meet its own abuse monitoring obligations.
We do not build a shared model across customers. A customer's configuration, prompts and data do not improve another customer's results.
Aggregated, de-identified operational telemetry under clause 8.6 of the Terms of Service is not training data and is not used as training data.
9. Known limitations
Say the quiet part out loud
Language models produce fluent text. Fluency is not accuracy. A model will sometimes state, in confident and well-formed language, something that is simply not true. This is usually called hallucination. It is not a bug we have fixed and it is not a bug anyone has fixed.
Hallucination. A model can invent a citation, a section number, a date, an amount, a name or an entire obligation. The invented item will usually look exactly like a real one. Anything a proposal asserts as a fact must be checked against the source before release.
Currency. A model's training data has a cut-off. It will not know about a regulation, a rate or a form that changed after that date unless we have put the current version in front of it.
Extraction errors. A model reading a document can misread a figure, transpose digits, attach a value to the wrong field, or miss a page. Rates are good and are not perfect.
Ambiguity. Where a document or an instruction is ambiguous, a model will pick a reading and will not usually tell you that it picked.
Bias. Models reflect their training data. Output can carry bias, including bias that matters where the output touches people.
Non-determinism. The same input can produce different output on different runs.
What we do about it. We ground the model in the customer's own records where we can, we show the source alongside the proposal where a source exists, we keep the release gate on everything that matters, and we record what was proposed so that an error can be found afterwards and traced. None of that makes the output correct. The release is where correctness is decided.
10. Prompt injection and untrusted input
A large part of what our models read is untrusted: an invoice from a supplier, an email from a stranger, a scraped page, a document a user uploads. Text in those sources can be written specifically to instruct the model, for example to make it exfiltrate data or to make it propose a payment to the wrong account. This is prompt injection.
We treat all such content as data, never as instructions. Content read from a document, a message, a web page or a third party system does not carry authority to change what the system does.
Model output does not by itself widen a seat's bounds, change an authority, add a recipient outside the permitted list, or reach a system that the seat is not permitted to reach. Those limits are enforced outside the model.
The release gate is the structural mitigation. A successful injection can at worst produce a bad proposal. A bad proposal still has to be released by a person who can see what it would do.
Where an act would send money or data to a destination not previously used by that customer, it is flagged to the releasing person as a new destination.
We do not claim that injection is solved. It is not solved anywhere. We claim that the architecture limits what a successful injection can achieve.
11. Human oversight and escalation
Every tenant has at least one named person with release authority. A tenant cannot operate without one.
A releasing person may refuse or escalate any proposal. The system records the refusal.
Where a proposal falls outside a seat's bounds it is not offered for release to that seat. It is escalated to a seat that holds the authority, or it stops.
How to escalate to us. Write to ops@kragos.app. Say that it is an AI governance matter. We will acknowledge within 5 business days. If a capability is producing output that is materially wrong, we will investigate, and we will disable the capability for that tenant while we do if the customer asks us to.
A customer may ask us to disable any AI capability in its tenant, in whole or for a class of act. We will do it.
We do not require a customer to use an AI capability in order to use the rest of a product.
12. The EU AI Act
KRAGOS is established in South Africa and does not currently place its products on the European Union market. This clause states the position we take now and the position we will take if that changes.
Transparency obligations, accepted now. Regulation (EU) 2024/1689, the Artificial Intelligence Act, imposes transparency obligations on limited risk systems in Article 50. We accept and apply those obligations now, voluntarily, whether or not the Act applies to us. In practice:
- a person interacting with the assistant is told that they are interacting with an AI system;
- AI generated or AI assisted content produced by the products is identifiable as such within the product, and the STEMPA record says which model produced it;
- where a product produces synthetic audio through the voice rail, it is disclosed as synthetic;
- the limitations in clause 9 are published rather than buried.
High risk, and who the deployer is. Annex III of the Act treats certain uses as high risk, including uses in employment and worker management, and in access to essential private and public services. Where output from a KRAGOS product is used to inform a decision about an individual in employment or in access to services, the customer is the deployer of that system and remains responsible for that decision. KRAGOS provides the record. KRAGOS does not provide the decision.
A customer that deploys a KRAGOS capability into a high risk use is responsible for the deployer obligations that attach to it, including human oversight, input data relevance, monitoring, and informing the affected person. The release architecture supports those obligations. It does not discharge them.
We do not market any KRAGOS capability as a system for evaluating, ranking, scoring or selecting natural persons, and we do not supply one.
Prohibited practices. We do not build, and we will not build, a capability whose purpose is social scoring, emotion inference in the workplace or in education, biometric categorisation on protected characteristics, or untargeted scraping of facial images, being practices prohibited by Article 5 of the Act.
If we accept a customer that places our products on the Union market, we will complete the provider assessment that the Act requires before that customer goes live, and we will publish the outcome here.
13. Governance inside KRAGOS
A change to a model, a prompt, a bound or a release rule is itself a change that is proposed, reviewed and released, and it is recorded.
We test a capability before it is enabled for a customer, and we keep the evidence.
We do not enable a new AI capability in a customer's tenant without telling the customer what it does and what it can propose.
14. Changes to this statement
We will publish material changes to this statement. A material change is one that changes what the AI is permitted to do, adds or changes a model provider, changes the release rule, or changes the position in clause 8.
A material change raises the version number, updates the last updated date, and is notified to customers in writing before it takes effect.
Superseded versions are kept and will be provided on request to ops@kragos.app.
AI Governance, version 1.0, last updated 5 September 2026. Published by Ecopackaging (Pty) Ltd (registration number 2014/032538/07, VAT registration number 4530265216) trading as KRAGOS, 750 Nieuwhout Street, Garsfontein, Pretoria, 0081, South Africa. All enquiries and notices to ops@kragos.app. Information Officer: Francois Petrus Heunis. Governed by the law of the Republic of South Africa; the parties consent to the jurisdiction of the Gauteng Division of the High Court of South Africa, Pretoria.
