Why governance as a phase label fails
Open almost any Turkish consultancy page on enterprise AI and you will find a nine-phase diagram with Governance sitting somewhere between Deployment and Scaling. There is nothing behind the box. No fields, no thresholds, no owner, no artefact anyone could produce on request. Governance drawn as a phase implies it happens once and then finishes, which is exactly wrong: it is a set of running processes that outlive the project that created them. A phase ends. An inventory does not, a change-control process does not, and an incident runbook is only useful on the day nobody planned for.
The consequences show up in project outcomes rather than in audit findings. Gartner's June 2025 press release, based on a poll of over 3,400 respondents, predicted that over 40% of agentic AI projects will be canceled by the end of 2027, citing escalating costs, unclear business value and inadequate risk controls. Read that list carefully, because none of the three is a modelling problem. They are all governance problems in the operational sense: nobody was tracking spend per system, nobody had defined what success meant, and nobody had decided what the system was allowed to do on its own.
The scale of the exposure is growing at the same time. Gartner also expects 40% of enterprise applications to feature task-specific AI agents by the end of 2026, up from less than 5% in 2025. An organisation that had three AI systems last year and will have forty next year cannot govern them through a quarterly steering committee and a shared spreadsheet that one person maintains. It needs the same thing any other production estate needs: an inventory with owners, a tiering rule, change control, an incident process and evidence. This article publishes those artefacts in the form we actually use.
The AI inventory: what a row must carry
The inventory is the foundation, because every other control is a query against it. One row per AI-touching system, and that includes features bought inside SaaS products, internal scripts calling a model API, and the pilot someone built in a weekend that is now in a customer workflow. The first field is a stable system identifier and a human-readable name, and the second is an owner who is a named engineer rather than a department. Departments do not answer questions at 2am. If a row has no named owner it is not governed, and the honest thing to do is either assign one or decommission the system.
Then the context fields. The business process it serves, in one sentence, written by the business rather than by engineering. Your role for that system, provider or deployer, because the obligations under the EU AI Act are asymmetric and the roles are not stable: rebranding or substantially modifying a third-party system can turn a deployer into a provider. Whether the output reaches the European Union, as a boolean, because that single field decides whether the AI Act applies at all and it is the one sales will change without telling you. The lawful basis under Turkish law, referencing Law 6698, and whether special-category data is involved under Article 6.
Then the technical fields. Model family, exact version and hosting location, because a pinned version is a prerequisite for every evaluation claim you will make. Data categories consumed and produced. The risk tier from the rubric below. The human oversight pattern in use. A reference to the evaluation suite that covers this system, by repository path rather than by description. Log retention for telemetry and for content, as two separate numbers. And the estimated monthly inference cost, which is not a compliance field but is the one that gets the inventory read by people who would otherwise ignore it.
Finally the lifecycle fields, which are the ones teams forget and later miss most. Date of last review and the name of the reviewer. Date of last material change. Open findings, with severity. And a decommission trigger, meaning the condition under which this system should be switched off: the process it supports ends, usage falls below a threshold, the model version is withdrawn, or the owner leaves without a successor. Without that field, estates only ever grow. In organisations we have worked with, building this inventory for the first time takes four to eight weeks of part-time effort and reliably uncovers two to five systems nobody had recorded.
A risk-tiering rubric a team can score in twenty minutes
Tiering fails when it becomes a philosophical exercise. Make it a short scored rubric that two people can complete for one system in twenty minutes and reproduce next quarter. We score six dimensions from zero to three. Reversibility: can the effect of a wrong output be undone, and at what cost. Person affected: does the output bear on an identifiable individual's rights, money, employment or access to a service. Data sensitivity: does the system touch special-category data under Article 6 of Law 6698. Autonomy: does the system suggest, act with confirmation, or act alone. Blast radius: how many people or records can one bad run affect. External visibility: does output reach customers, the public or a regulator.
The sum maps to four tiers, and the tier determines obligations rather than attitude. Tier 0, internal experiments on non-personal data, needs an inventory row and nothing else. Tier 1, assistive systems where a human reads every output before it does anything, needs an evaluation suite, structured logging and a named owner. Tier 2, consequential systems that affect a person or money but whose effects can be reversed with effort, adds a documented oversight pattern, change control with staged rollout, an incident runbook entry and quarterly review. Tier 3, systems that are regulated, irreversible or highly autonomous, adds pre-deployment sign-off, a formal impact assessment and monthly review.
Two rules keep the rubric honest. First, any single dimension scored at three forces at least Tier 2 regardless of the total, because an irreversible action or special-category data cannot be averaged away by low scores elsewhere. Second, the tier is re-scored on material change, and a tier increase blocks release until the additional controls exist. Write the score, the date and the two names on the record. That record is what an auditor asks for first, it survives staff turnover, and it forces the uncomfortable conversation early, which is the entire point of doing it before rather than after deployment.
Human oversight: three patterns and what each actually costs
Approve-before-act puts a human between the model and the effect. Nothing is sent, written or paid until someone approves it. It is the right pattern for irreversible actions, for external communication in regulated contexts, and for any Tier 3 system in its first months of life. The cost is real and should be modelled before launch, not after: it adds queue latency measured in minutes to hours, and it consumes reviewer capacity in direct proportion to volume. The failure mode is rubber-stamping, and it is close to inevitable when the queue grows beyond what reviewers can genuinely read. Above roughly eight per cent of production volume, review quality collapses within weeks.
Review-after lets the system act and has a human check a defined slice afterwards, usually everything above a confidence threshold or everything in a sensitive category. It suits reversible actions with moderate blast radius, and it keeps latency at zero for the user. Its failure mode is alert fatigue: reviewers who see mostly correct outputs stop reading carefully, and the signal that mattered arrives in a batch of forty that all looked the same. Counter it by tuning the trigger so the review queue stays interesting, typically holding a two to eight per cent hit rate, and by rotating reviewers rather than dedicating one person permanently.
Sample audit reviews a small random slice, one to five per cent depending on tier, to measure quality rather than to catch individual errors. It is the correct pattern for Tier 1 systems at scale, and the wrong one for anything irreversible. Its failure mode is unrepresentative sampling: teams sample what is easy to sample, which is usually short outputs from the busiest tenant on weekday afternoons. Stratify deliberately across tenant, document type, output length and time of day, and record the sampling frame so that next quarter's numbers are comparable with this quarter's.
Detecting rubber-stamping is a measurement problem with a simple answer, and we instrument it from day one. Track median review time per item against output length; a median of under four seconds on a three-hundred-word draft means nobody read it. Track the approval rate: a reviewer approving ninety-nine per cent of items is either supervising a perfect system or not supervising at all, and you can tell which by inserting known-bad items into the queue at a low rate and measuring the catch rate. Track per-reviewer variance. Publish these numbers to the reviewers themselves, because the metric changes behaviour faster than any policy sentence.
Model and prompt change control
Prompts are code and belong in version control, reviewed like code, with the model version pinned alongside them. The anti-pattern is a prompt edited in a hosted playground and pasted into production, after which nobody can say what the system was doing last Tuesday. Keep the prompt, the model identifier and version, the retrieval configuration, the chunking parameters, the tool schemas and the guardrail settings in one versioned bundle, and give each deployed bundle an identifier that appears in every log line. That single identifier turns an incident investigation from archaeology into a query.
Define what triggers re-evaluation, and automate it rather than trusting judgement under deadline. Any prompt change, any model version change including a supplier-side one, any change to retrieval parameters, chunking or the embedding model, any index rebuild, any tool schema change, and any guardrail change. Each of those can move behaviour more than people expect: in our experience changing the embedding model alone can shift retrieval quality by five to fifteen per cent in either direction, which is enough to break a system that was tuned around the old ranking without anyone touching the prompt.
Roll out in stages and keep the ability to go back. Shadow mode first, where the new bundle runs on live traffic and its output is logged but not served, for long enough to compare on real distribution rather than on your test set. Then a small percentage of traffic, then broader, with automatic rollback on the metrics you defined beforehand. The silent model swap is the case that catches everyone: a hosted model version is deprecated on the supplier's calendar, your pinned version stops resolving, and behaviour changes without any commit in your repository. Track supplier deprecation notices in the inventory and budget one re-validation cycle per model per year.
Incident taxonomy and the runbook
You cannot run an incident process without categories, because the response differs by kind. Ours has six. Harmful or inappropriate output reaching a user. Data leakage, meaning personal or confidential data appearing where it should not, including in logs. Prompt injection or jailbreak, whether attempted or successful. A hallucinated fact acted upon, where a wrong output caused a real decision or action. Availability or cost blowout, including runaway loops and token spend anomalies. And access-control failure in retrieval, where a user received content they were not entitled to see, which in a RAG system is the most consequential category of all.
Severity is defined by effect, not by embarrassment. S1 means personal data exposed to an unauthorised party, an irreversible action taken wrongly, or a system unavailable in a business-critical path; it pages the on-call engineer and the system owner immediately, at any hour. S2 means a contained incident with a workaround, reviewed the same business day. S3 means a quality defect with no external effect, triaged in the normal backlog. Write the definitions down before you need them, because severity assigned during an incident by the person who caused it is always one level too low.
Containment options should exist as switches, not as plans. Disable a specific tool or action while leaving the assistant readable. Drop to a safer or smaller model. Restrict the retrieval scope to a known-clean index partition. Freeze the affected tenant. And a genuine kill switch that stops the system without a deploy, tested quarterly, because an untested kill switch is a paragraph rather than a control. For each of the six categories, the runbook names the first responder, the containment step, who is notified internally, and the threshold at which legal and the data protection function are brought in.
Preserve the evidence, and decide in advance what that means. On declaring an incident, place the relevant logs, prompts, responses, retrieval traces and model bundle identifiers under a hold that survives the normal retention job. This is the single most common operational mistake we see: an incident opens on day one, the seven-day content retention window closes on day seven, and the investigation loses the material it needed on day nine. Then run a written post-incident review with a cause, a corrective action with an owner and a date, and a new evaluation case that reproduces the failure so the same defect cannot ship twice.
Evaluation evidence that doubles as technical documentation
The most useful thing to understand about AI Act technical documentation is that it is mostly evidence you should be generating anyway. A versioned evaluation dataset with documented provenance is a data governance record. Evaluation runs tied to bundle identifiers are accuracy and robustness claims. Drift monitoring is post-market monitoring. Human override statistics are proof that oversight is real rather than declared. Incident records are the serious-incident trail. The mechanics of building this layer are covered in AI observability and evaluation, and it is where most of the engineering effort in a governance programme actually goes.
Generate the document rather than writing it. A quarterly technical file assembled by hand goes stale within one release cycle and is wrong in the specific way reviewers notice, because the version numbers in the text no longer match the version numbers in production. Build a job that reads the model registry, the evaluation results, the data lineage, the change log and the incident tracker, and renders the file with a generation timestamp. Everything a human writes by hand should be judgement: the intended purpose, the known limitations, the residual risk statement. Everything else should be a query.
The timing argument matters more than the format. Evidence cannot be produced retrospectively. If you decide in 2027 that you need eighteen months of evaluation history for a system that has been live since 2025, you cannot manufacture it. The deferred deadlines under Regulation (EU) 2026/1744, which moved Annex III standalone high-risk obligations to 2 December 2027 and Annex I product-embedded high-risk obligations to 2 August 2028, do not create log data you never collected. The full timeline, including the Article 50 transparency duties that were not delayed, is in our breakdown of the AI Act after the omnibus.
Who owns what
Three named roles per system, and no committee in the accountable column. The engineering owner is accountable for the system behaving as specified: the evaluation suite, the logging, the change control, the incident response. The business process owner is accountable for whether the system should exist at all, what the acceptable error rate is, and what the human oversight pattern costs their team in reviewer hours. The risk or legal reviewer is consulted on classification, lawful basis and disclosure, and is informed on changes. Everyone else is informed. Three names, written on the inventory row, with a date.
The anti-pattern is the AI governance committee that owns everything and therefore ships nothing. It meets monthly, reviews a paper, requests more information, and becomes an approval queue that engineering learns to route around. Committees are good at a small number of things: setting the tiering rubric, approving Tier 3 systems before deployment, reviewing incidents above S2, and arbitrating when the engineering owner and the business owner disagree. They are bad at everything operational. If your committee's agenda has more than five recurring items, it has absorbed work that belongs to a named individual.
Two adjacent functions need explicit homes as well. Fairness and bias review needs an owner, a method and a cadence rather than a paragraph in a policy, and the practical approaches are covered in AI ethics and bias. Data protection needs a standing relationship rather than a ticket, because the questions that matter arrive during design and not at launch; the engineering translation of the Turkish guidance is in our read of KVKK's generative AI guide. Both work best embedded in the delivery team's rhythm rather than as external gates.
The first ninety days, in order
Days one to thirty: inventory and tier. Build the row schema above, populate it for every system you can find, and score the rubric. Expect the list to be longer than anyone predicted and expect two to five systems that nobody had recorded. Assign a named owner to every row and delete or decommission anything nobody will claim, which is usually between ten and twenty per cent of the list. This is deliberately cheap work, it needs one engineer and one person from the business, and it produces the artefact every later decision depends on.
Days thirty to sixty: change control and oversight. Move prompts into version control, pin model versions, define the re-evaluation triggers, and stand up staged rollout with automatic rollback. Then design the oversight pattern for each Tier 2 and Tier 3 system as software rather than as a policy sentence: a queue, a service level, an override, and a record of who used it. Instrument the rubber-stamping metrics from day one, because retrofitting them means asking reviewers to justify past behaviour, which is a conversation nobody wins and a dataset you will never get.
Days sixty to ninety: incidents and evidence. Write the six-category taxonomy with severity definitions, build the containment switches and test the kill switch, and set the evidence hold so that declaring an incident suspends the retention job. Then wire the technical documentation generator and run it once. Set the review cadence and put it in a calendar with named attendees, because the most common failure of a governance programme is not that it was never built but that it was built once and never revisited. Quarterly suits most portfolios; monthly if you are shipping agents, for reasons set out in our article on AI agents.
How we run this at HatsonTech
We build these artefacts into delivery rather than selling them as a separate governance workstream, because a governance programme that produces documents nothing else consumes will rot and the audit will find that it rotted. In practice that means the inventory row exists before the first model call, the evaluation suite is in CI before the pilot demo, prompts are in the repository from the first commit, and the incident taxonomy is written during design when it is a ten-minute conversation rather than during an outage when it is not. None of this is expensive at the start. All of it is expensive to retrofit.
What we see most often in Turkish organisations is asymmetric maturity: a competent legal position with no systems evidence beneath it. There is no record of who approved a prompt change, no versioned evaluation set, no way to demonstrate that a deletion request reached every store, and no log that would let anyone reconstruct a decision from six months ago. The same instrumentation that closes that gap is what lets a team change models without fear, which is why we argue for it on engineering grounds first and compliance grounds second. The domestic legal picture that sits underneath it is set out in where Turkey's AI regulation actually stands.
If you want a starting point, the inventory row schema and the six-dimension rubric in this article are enough to run a first pass yourself in an afternoon. Where teams usually want help is the layer below: the evaluation harness, the logging and retention design, the staged rollout machinery and the documentation generator, which is ordinary platform engineering with a compliance side effect. That is what our custom software engineering practice builds, and it is what we would look at first. Bring your current system list and we will tell you which rows have no owner.