Visibility
Complete free example
The question
What AI are we actually running?
Purpose
Visibility establishes a complete and current record of the AI systems the organization operates, with enough detail on each to support the domains that follow. Where the record is incomplete, the scope of every subsequent assurance activity is unknown. Assurance over an unknown scope is not partial assurance. It is false assurance, and it is acted on as though it were complete.
Scope and definitions
In scope
- Systems developed internally that apply machine learning or generative models.
- Products procured specifically for their AI capability.
- AI capability activated within third-party products already in use.
- General-purpose AI assistants used for organizational work, whether procured or not.
- Agentic systems that take action in other systems without a person approving each step.
Out of scope
- Systems operating solely on synthetic data in an isolated environment with no connectivity to production. These are recorded, but remain out of scope for the downstream domains until that isolation ends.
- AI system
- A system whose output is produced wholly or partly by a machine learning or generative model, where that output informs a decision, a communication, or an action affecting the organization, its customers, or its staff.
- In production
- In use for organizational work, whether or not it was formally released, procured, or approved.
Background
Why this domain is first
AI enters an organization through three routes. Only deliberate development or procurement necessarily involves a new project or purchasing decision.
Systems built or procured deliberately can be recorded and reviewed through project and procurement controls. Capability activated inside products already in use can arrive as a vendor feature release without a new procurement decision or inventory entry. Tools adopted by individual staff can arrive without explicit approval.
An inventory constructed from the first route describes a fraction of what is running, and describes it with complete confidence. That combination of partial coverage and total confidence is what makes visibility the first domain rather than an administrative matter placed later.
The consequence is structural. Where 40 AI systems are in production and the risk register covers four, the result is not partial assurance. It is false assurance, which is materially worse than none, because false assurance is acted on. A reader who knows the picture is incomplete asks further questions. A reader holding a clean four-system report does not.
The same applies to every domain that follows. Accountability cannot be assigned for systems that have not been identified. Controls cannot be tested on systems absent from scope. Obligations cannot be mapped to uses never declared. Each of those failures is invisible, and each resembles success in a board pack.
Counting and estimating
A stated count is the beginning of the inquiry, not its conclusion. The material question is how the number was produced.
There are two possibilities. Either the systems were counted, in which case the method and its coverage can be examined. Or the number was estimated, in which case an opinion has been presented in the format of a fact. The distinction matters because opinions do not survive contact with a regulator, a claimant, or a journalist.
Scope definitions and apparent completeness
Definitions determine what a count means, and a narrow definition is the most common reason an inventory appears complete when it is not.
A definition limited to systems the organization deliberately built or procured as AI excludes the assistant embedded in the document platform, the scoring feature in the recruitment tool, and the summarization now applied by default across the email system. Each of those contributes to decisions affecting people. None passed a procurement gate. A narrow definition does not remove them from operation. It removes them from management.
This is why VIS-3 requires the definition to be documented and approved rather than merely applied. An approved definition can be examined and challenged. An implicit one cannot.
The limits of board involvement
Constructing and maintaining the inventory is management work. A board that begins specifying data fields has substituted operation for oversight.
The board's interest is confined to three properties, and each is established by asking until it is answered without qualification:
- Accountability for accuracy rests with a named role (VIS-2).
- The scope definition was chosen deliberately, documented, and approved, and is broad enough to include what arrived without a decision (VIS-3).
- Somebody independent has looked for what is missing and reported what they found (VIS-7).
The third distinguishes an organization managing this domain from one documenting it. Producing a list requires only effort. Attempting to prove the list wrong requires intent.
Control objectives
A single inventory of AI systems in production is maintained.
- The inventory, with its last-verified date and the name of the person who verified it.
- An inventory without a verification date is a document rather than a control. Where the most recent date coincides with the last board paper, it is produced for the board rather than used by the business.
Indicator. Count of AI systems recorded, and net change since the previous report.
A named role is accountable for the accuracy of the inventory, distinct from responsibility for maintaining it.
- The role description or delegation recording that accountability.
- Accountability for accuracy and responsibility for upkeep are different obligations. Where only the second is assigned, nobody answers for what the inventory omits.
The definition of AI system used to scope the inventory is documented, approved, and encompasses capability embedded in third-party products.
- The written scope definition, and the record of who approved it.
- A narrow definition makes a thin inventory appear complete. Where the definition excludes embedded features or general-purpose assistants, the resulting count carries little meaning.
Each inventory entry records the attributes the subsequent domains require, including accountable owner, purpose, data used, decision authority, vendor, and risk classification. For material systems, it also records the system boundary and dependencies: models, system instructions, retrieval sources, memory, tools and their permissions, connected data stores, human decision points, and material vendors.
- The inventory schema, and a sample of completed entries.
- Entries populated only with a name and an owner cannot support classification, control testing, or obligation mapping. The gaps determine which later domains are unassessable.
- For material systems, the system and dependency map behind each entry.
- Behavior emerges from the combination of model, instructions, retrieval, tools, and permissions. An entry naming only the product conceals the configuration that creates the exposure.
The inventory is reconciled at a defined frequency against sources independent of itself.
- The procurement register for the preceding 24 months, filtered for products with AI capability.
- The difference between that register and the inventory is the AI that entered through a route nobody was monitoring.
- Administration console exports from the major platforms in use, showing which AI features are enabled and by whom.
- Whether features were enabled deliberately by someone with authority to do so, or simply became available and were left on.
- Network egress or cloud access security broker reporting for traffic to public AI services.
- The scale of use no inventory process will capture, and whether anyone reviews it.
- The reconciliation record, listing discrepancies found and their resolution.
- Repeated reconciliation that finds no discrepancies should prompt challenge as to whether the sources are genuinely independent and sufficiently broad.
Indicator. Date of most recent reconciliation, and count of discrepancies identified and closed.
A defined intake route records an AI system in the inventory before it reaches production.
- The intake process document, and evidence of the most recent systems admitted through it.
- Whether visibility is a continuous process or a periodic reconstruction. Where no intake route exists, the inventory is accurate only on the day it is rebuilt.
The completeness of the inventory is tested by a party independent of the function that maintains it, and the result is reported to the board.
- The most recent completeness test, its scope, its findings, and the board minute recording receipt.
- Whether anyone has attempted to prove the inventory wrong. Anybody can produce a list. Few have tried to disprove their own.
Indicator. Date of most recent independent completeness test, and count of unrecorded systems found.
Assurance states
What this domain looks like in each state. The five states themselves are defined on the assurance states page.
- 1AbsentNo inventory exists. The number of AI systems in production cannot be stated.
- 2Ad hocA list exists because an individual produced one. It has no accountable owner, no defined scope, and no refresh cycle.
- 3DefinedA documented inventory process exists, with an accountable owner, an approved scope definition, an intake route, and a defined refresh cycle. The inventory is maintained against itself.
- 4EvidencedThe inventory produces evidence a third party could test: reconciliation records against independent sources, discrepancies found and resolved, and entries carrying the attributes, and for material systems the dependencies, that the later domains require.
- 5AssuredCompleteness has been independently tested by a party that went looking for omissions. The result was reported to the board, the gaps were closed, and the test is repeated.
Standards mapping
All eight domains side by side, and what a mapping does and does not claim, are in the standards mapping (Professional Edition).
United States
- NIST AI RMF 1.0 (2023) GOVERN 1.6: mechanisms are in place to inventory AI systems and are resourced accordingly.
- NIST AI RMF 1.0 (2023) MAP 1, establishing context for a system already identified.
International
- ISO/IEC 42001:2023 Clause 7.5, maintaining the management system's documented information.
European Union
- EU AI Act Article 49, registration of specified AI systems by their providers and certain public-authority deployers.
- EU AI Act Articles 11 and 12, technical documentation and automatic logging for high-risk AI systems.
- General Data Protection Regulation Article 30, records of personal-data processing activities, subject to its exceptions. These record processing activities, not an inventory of all AI systems.
Version 1.1 · Updated October 6, 2026 · Cite objectives as TAL 1.1 / VIS-3