Seven questions to ask of your own AI governance
Most organisations now have a position on responsible AI, but far fewer can show it working. In a 2025 study by the World Economic Forum and Accenture of 1,500 companies, fewer than 1% had fully operationalised responsible AI, and 81% remained in the two earliest stages of maturity [1]. The share doing it systematically had risen, but only to 19%, from 14% the year before [1]. The gap is rarely a matter of intent. It is the work of turning a policy into a record that holds up when someone looks. ,
That work matters more each year, because the people who now ask about AI governance want the evidence rather than the claim. The EU AI Act frames its obligations for higher-risk systems around documentation, logging and monitoring that can be produced on request, and ISO/IEC 42001, the first certifiable management standard for AI, is built on auditable records [2] [4]. In this region, the direction is the same: Singapore's Model AI Governance Framework and the ASEAN Guide on AI Governance and Ethics both point towards AI that is documented and accountable [6] [7]. Customers and auditors ask for the same.
The quickest way to find the weak points in your own governance is to put a few questions to your operation before someone else does. The seven below are those questions. Each has a strong answer and a weak one, and knowing which you would give is the point of asking.
1. Can you show, in one place, what AI you have in production?
You can only govern what you can see, which is why frameworks start here. The Map function of the NIST AI Risk Management Framework begins by establishing the context and inventory of AI systems in use, and ISO/IEC 42001 expects an organisation to keep records of the AI systems it runs [3] [4]. A strong answer is a single, current inventory that names each model in production, the version live today, the data behind it and the person accountable for it. A weak answer is a spreadsheet last updated months ago, or a picture held in a few people's heads. If assembling the list would take a week of asking around, that is the answer.
This is a more common position than a published policy suggests. The maturity gap in the WEF and Accenture research points to exactly this: organisations with the intent, often the policy, and sometimes the inventory, but not yet the practice [1].
2. Do you know where your data came from, and whether you are entitled to use it as you do?
Data has a provenance and a set of terms it was obtained under, and using it beyond those terms is a governance failure whether or not anyone notices. The EU AI Act requires that data used to train, validate and test higher-risk systems be governed for quality and relevance (Article 10), and the direction of regulation is towards disclosure of provenance more broadly: providers of general-purpose models must now publish a summary of the sources their training data was drawn from [2] [5]. A strong answer is lineage for each significant dataset together with the terms attached to it, so you can state where the data came from and that you hold the right to use it as you do. A weak answer is data whose origin, or whose licence, no one can now state with confidence.
TTMI AI SDLC Resource Library Several of these questions turn on terms with exact meanings, shadow AI, data lineage and the standards behind them. The AI SDLC reference library defines each in plain terms and links the frameworks it draws on.
3. When a model last drifted or got something materially wrong, is there a record of what changed?
Models drift from the behaviour they were validated for. The real question is whether the drift is caught and recorded, or noticed only once something downstream has broken. The EU AI Act treats this as continuous work. Providers of higher-risk systems must run post-market monitoring that actively and systematically collects and analyses performance data across the system's life (Article 72), and the automatic logs required under Article 12 exist partly to identify when a system starts to present a risk or has been substantially changed [2]. NIST's Measure function likewise treats testing and monitoring as continuing after deployment, not ending at it [3]. A strong answer is monitoring that flags material change and an incident record that captures what moved, when, and what was done about it. A weak answer is no record at all, because nothing was watching until the failure surfaced.
4. If you were asked to prove a decision was properly governed, how fast could you produce it?
In a governed lifecycle the evidence is produced as the work happens, so it exists before anyone asks, and the test is how quickly you can produce it. The EU AI Act makes the standard concrete. Technical documentation for higher-risk systems must be complete enough for an authority to assess the system without reverse-engineering it (Article 11 and Annex IV), automatic logs must be kept over the system's life, and deployers must retain those logs for at least six months (Articles 12 and 26) [2]. A strong answer is that the record already exists and can be produced in hours: the tests that were run, the approvals given, the version history behind that decision. A weak answer is a scramble to reconstruct after the fact, or nothing to produce at all.
One caution here. Holding a certificate against a standard is not the same as being able to produce the records. A management-system certificate shows you have organised how you govern AI. It does not, by itself, generate the logs and documentation an auditor or regulator will actually ask to see [2]. The record has to be real.
5. Do you know everywhere AI is actually in use, including features switched on in tools you already had?
A governed lifecycle can only cover the AI it knows about, and a good deal of AI now enters an organisation quietly: a tool a team adopted on its own, or an AI feature enabled inside software already in use. The scale is not marginal. In a 2023 Salesforce survey of more than 14,000 workers, most of those using generative AI at work had used tools their employer had not approved, and MIT research in 2025 found employees using personal AI tools at the large majority of companies studied [8] [9]. A strong answer is a means to discover that use and a route to bring it into governance. A weak answer is no visibility of it at all, which means it is running outside every control you have.
6. Can you govern the AI you buy to the same standard as the AI you build?
Much of the AI an organisation relies on is bought rather than built, and it tends to receive far less scrutiny. The EU AI Act assigns responsibilities along the whole value chain (Article 25), and buying a model does not transfer the responsibility for it. To a customer or a regulator, you are the supplier of the final service, and vendor due diligence is yours to do [2]. A strong answer is that bought-in AI is assessed and held to the same evidence standard as AI built in-house, with the vendor's controls and documentation examined at procurement rather than assumed. A weak answer is third-party AI treated as a black box, sitting outside the governance applied to everything else.
7. When did you last test a model against how it could be misused or attacked, rather than only whether it works?
Functional testing asks whether a model does what it should. It does not ask how the model could be turned, misled or attacked, and that is the testing most often skipped. NIST recommends red teaming, the adversarial testing of a system under stress to find its failure modes, as part of measuring AI risk, and publishes a taxonomy of adversarial attacks on machine learning to test against [3] [10]. Others map the same ground. MITRE's ATLAS catalogues real attack techniques such as data poisoning and model evasion, and the OWASP Top 10 does so for large language model applications [11] [12]. The point of all of it is to find the failure before a customer, a regulator or an attacker does. A strong answer is adversarial testing done deliberately, with a record of what was tested, what was found and what changed as a result. A weak answer is functional testing alone, with the ways the model could fail left unexamined.
Cybersecurity at TTMI The same discipline runs through vehicle cybersecurity, where a documented, evidenced security lifecycle has long been a condition of market access. It is central to how TTMI secures connected fleet and mobility systems.
What the answers tell you
Answered honestly, the seven give a map of where your AI governance holds and where it gives way. The weak answers tend to travel together. An organisation that cannot produce its inventory quickly usually cannot produce its evidence quickly either, because both come from the same underlying discipline.
A governed AI lifecycle closes those gaps. It turns each of these questions from something you assert into something you can show, because the record is built while the work is done.
Sources
[1] WEF AI Governance Alliance and Accenture, Advancing Responsible AI Innovation: A Playbook, 2025. https://www.weforum.org/publications/advancing-responsible-ai-innovation-a-playbook/
[2] European Commission, EU AI Act (Regulation (EU) 2024/1689), Articles 10, 11, 12, 25, 26 and 72. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
[3] NIST, AI Risk Management Framework (AI RMF 1.0), 2023.
[4] ISO/IEC 42001:2023, Information technology, Artificial intelligence, Management system.
[5] European Commission, GPAI training-content summary template, 2025.
[6] IMDA and AI Verify Foundation, Singapore Model AI Governance Framework.
[7] ASEAN Guide on AI Governance and Ethics, 2024.
[8] Salesforce (with YouGov), generative AI at work survey, October 2023. https://www.salesforce.com/news/stories/ai-at-work-research/
[9] MIT Project NANDA, The GenAI Divide: State of AI in Business 2025, July 2025.
[10] NIST AI 100-2, Adversarial Machine Learning: A Taxonomy and Terminology.
[11] MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems).
[12] OWASP Top 10 for Large Language Model Applications.
Comments