AI Trust Documents
Selling AI no longer ends with showing the product. A file is asked for alongside it. For high-impact systems, Türkiye’s AI Action Plan foresees an extended algorithmic impact assessment, a publicly available summary model card and a detailed technical file for supervisory bodies. Medium-risk applications need a short-form impact assessment. Low-risk ones need simple checklists. So the burden is scaled to the risk. Not every product prepares the same file.
These documents look like bureaucracy at first. But within a few years they will be the shared language of tenders, corporate purchasing and export. Whoever learns the language early gains an advantage.
Why Is the Question Being Asked Now?
BU BÖLÜMÜN ÖZETİ
- Public procurement is being tied to documents
- Risk tiering is settling in
- The export door asks for the same file
- Testing capacity is being built
Four developments pushed documentation forward.
Public procurement is being tied to documents
High-impact systems deployed in the public sector will pass certification and evaluation processes. Institutions will receive guides, checklists and standard templates, which also creates consistency between them. So for a seller, the document becomes part of the product. A product without one does not get through the public door. Corporate buyers are moving the same way; the procurement chain writes this condition explicitly.
Risk tiering is settling in
The plan adopts a proportionate risk approach. Not every system faces the same obligations, which is good news for small scale. The high-impact fields are named: health, education, employment, social assistance, credit scoring, biometric recognition, law enforcement and justice. Applications affecting children and vulnerable groups are in scope too.
The export door asks for the same file
For a model to be accepted globally, the buyer’s and the regulator’s questions need ready answers. The plan defines an “export-ready package” for this: from security testing to legal compliance, from performance documents to environmental impact. A file prepared for the domestic market works abroad too. The same effort opens two doors.
Testing capacity is being built
AI security evaluation capacity will be strengthened. The criteria are set: security, performance, robustness, bias, explainability, data protection. Test methods and guides will be developed for them. So the answer to “how will this be tested” is standardising too. That reduces uncertainty.
What Is Wrong?
BU BÖLÜMÜN ÖZETİ
- “This is for big companies”
- “We’ll prepare the documents when the product is finished”
- “Documents slow you down”
- “Our product is safe anyway”
Four assumptions misplace the documentation side.
“This is for big companies”
The obligation depends on the application’s risk level, not company size. A three-person team building a recruitment screening system sits in a high-impact field, because it touches people’s access to work. A hundred-person company building an internal reporting tool stays low-risk. The measure is not size. It is who the application touches.
“We’ll prepare the documents when the product is finished”
Documents written afterwards do not reflect reality. A model card explains three things: what data it was trained on, what limits it has and where it fails. That information gets recorded during development. It is not remembered later. Those who think they remember usually remember wrong.
“Documents slow you down”
The plan aims for the opposite: designing regulation as a structure that enables safe scaling rather than slowing innovation. In practice it works that way too. An undocumented product waits months in corporate purchasing. A documented one passes. What slows you is not the document but its absence.
“Our product is safe anyway”
Being safe and being able to show it are different things. A buyer does not purchase your good intentions. They purchase your evidence. And the form of that evidence is now standardising.
The Real Mechanism
BU BÖLÜMÜN ÖZETİ
- Part 1: the model card
- Part 2: the impact assessment
- Part 3: the technical file and tests
- Part 4: the human oversight record
A trust file has four parts.
Part 1: the model card
The model’s identity document. Purpose, use case, training and data sources, performance metrics, known limitations, risks and recommended conditions of use. It is kept short and published as a public summary. A well-written model card is also half your sales pitch; the buyer sees clearly what they are getting.
Part 2: the impact assessment
A document analysing the system’s possible effects on individuals, society and institutions in advance. It comes in short or extended form depending on risk level. Its real value is something else. It forces you to think about your own product. Who could be harmed? In what situation?
Part 3: the technical file and tests
The detailed record submitted to supervisors. It contains test methods, results and version history. High-impact systems will be assessed before going live and at major version updates. So this file is not prepared once and closed. It lives with the versions.
Part 4: the human oversight record
Where the system requires human approval, who holds stop authority, what happens on error. This is a design job before it is a documentation job; it gets written into the system before it reaches paper. A business that builds its approval flow upfront writes the document easily.
Who Is Affected, and How?
BU BÖLÜMÜN ÖZETİ
- The software producer
- The business using AI
- Those working in sensitive fields
- Consultants and integrators
Four profiles, four different burdens.
The software producer
The most directly affected. Documentation belongs in the product roadmap, not as a separate line item. Good news: a documentation routine built once gets reused at every version. Bad news: if it was never built, the first time is laborious.
The business using AI
You may carry responsibility even if you do not build. If you use a tool that produces decisions from customer data, asking the supplier for its documents is your job. A business that does not ask gets caught unprepared when a problem appears. Shifting responsibility to the supplier is not always possible either.
Those working in sensitive fields
Health, finance, education, employment. Obligations are heaviest here. But the most protected market is here too. Few players can carry the documentation burden, so competition thins. The burden is also an entry barrier.
Consultants and integrators
A new service area is emerging. Document preparation, running tests, compliance advisory. But note: compliance advisory does not mean taking over responsibility. Whoever stands behind the document is the product’s owner. The consultant helps; you sign.
Decision Order
BU BÖLÜMÜN ÖZETİ
- One: determine your risk level
- Two: start keeping records today
- Three: build oversight into the design
- Four: turn the file into a sales instrument
Four steps.
One: determine your risk level
Which field does your product, or the system you use, operate in? Who does it touch? Check the plan’s high-impact list. If high-impact, preparation starts now. If low-risk, a simple checklist suffices.
Two: start keeping records today
A model card cannot be written retrospectively. What data was used, which tests were run, which limits were found? Note these during development. Record-keeping is eighty percent of writing the document. The remaining twenty is organising.
Three: build oversight into the design
Approval points, thresholds, stop authority. These are not features added later. They are design decisions. Oversight added afterwards costs more and looks patched on.
Four: turn the file into a sales instrument
The document you prepare is not only for audits. Corporate buyers ask the same questions, often in more detail. Put the model card in your sales pack. If your competitor lacks one, that makes a difference. Buyers prefer prepared sellers.
Where to Start?
BU BÖLÜMÜN ÖZETİ
- Write down your risk level
- Open a simple record book
- Draft one model card
- Ask your suppliers
Four jobs.
Write down your risk level
One sentence. Which field, who it touches, which decision it produces. That sentence determines your whole obligation level.
Open a simple record book
Data sources, versions, tests, limits found. A spreadsheet suffices. What matters is keeping it regularly. Ten minutes a week is enough.
Draft one model card
For your most important current product. The first draft will be incomplete. The gaps show you what you need to collect.
Ask your suppliers
Do the AI tools you use have model cards and test information? Asking protects you. It also brings suppliers into line; one who cannot answer has told you something about their own state.
What Not to Do?
BU BÖLÜMÜN ÖZETİ
- Preparing documents by copying
- Hiding the limitations
- Preparing the document once and forgetting it
- Dumping compliance on one person
Four traps.
Preparing documents by copying
Templates are plentiful online. But writing someone else’s limitations into your product surfaces at the first audit question. A template gives a skeleton. The content comes from you.
Hiding the limitations
The most valuable section of a model card is its limitations. Writing what it cannot do is not weakness but maturity. Buyers know this; experienced ones read the limitations section first.
Preparing the document once and forgetting it
Models change, data changes, limits change. Documents get updated at major versions. An outdated model card is worse than none, because it gives wrong information.
Dumping compliance on one person
Documentation is not the technical team’s job alone. Risk assessment involves commercial judgement too. Which uses are acceptable gets discussed at the management table.
A Solid Digital Foundation
BU BÖLÜMÜN ÖZETİ
- The risk level statement
- The record book
- The model card archive
- The oversight design
Four stones.
The risk level statement
Which product sits at which level. Reviewed yearly; if the use case changes, the level changes.
The record book
Data, versions, tests, limits. The raw material of every document. The book comes before the document.
The model card archive
For every product and every major version. Both an audit file and a sales file.
The oversight design
Approval points and stop authority in writing. Read alongside the delegation ruler: which work the machine does, where the human steps in.
Frequently Asked Questions
Sık Sorulan Sorular
The obligation follows risk level; low-risk applications need only simple checklists. Determine your level first, then meet that level’s requirements. Also, most of the documentation burden is record-keeping, and done during development it is not extra work. The hard part is trying to remember afterwards.
Responsibility is shared. The developer answers for the model’s own properties. You answer for which job you use it in, with what data and for which decisions. The same model can be low-risk in one use and high-impact in another. What decides is not the model but your application. The supplier’s document is a starting point, not an endpoint.
The plan foresees two layers. The publicly available summary is the model card; the detailed technical file goes to supervisory bodies. So not everything gets published. The summary layer aims to explain conditions of use and limits, not the details of your training method.
Earlier on the public side: certification processes for high-impact systems deployed in public institutions are among the plan’s first targets. In the private sector, turning the rule set into legislation will take time. But waiting makes little sense. Whoever prepares when the rule appears is already late. Whoever starts keeping records now will have the file ready.