AI Incident Management Starts With These Two Questions

A structured intake begins by identifying the AI system and the organization’s relationship to it.

The first report rarely contains enough information to explain what happened. It may mention an inaccurate chatbot response, an unexpected automated decision, exposed information, or unanticipated behavior. But it may not identify the system configuration, business process, owner, or third party involved.

The organization’s relationship to the technology can be equally complex. It may have developed one component, deployed a vendor’s system, supplied data, used the output, or been affected by a system controlled elsewhere. Employees may also use AI tools outside approved processes.

These two questions do not determine fault or resolve the incident. They establish the operational facts teams need to route the matter, locate records, involve the right stakeholders, and begin a consistent investigation.

RadarFirst AI Incident Management (AIM) structures this intake so that the reporter does not need to assign responsibility or reach a legal conclusion. Teams can create an initial incident record, refine it as new facts emerge, and maintain continuity from intake through outcome.

Question 1: What AI system was involved?

Identify the complete AI system involved, not only the model, vendor, or reported incident type. Intake should capture what the system was doing, where it was used, and where relevant records may exist.

For operational intake, an AI system includes the components and operating context that produce or influence an output. Depending on the use case, that may include models, data sources, instructions, business rules, interfaces, integrations, safeguards, users, monitoring, and downstream actions.

An AI system could be:

•   A standalone product
•   A feature embedded within a larger application
•   An internally developed tool
•   A third-party service accessed by employees
•   A combination of models, data sources, integrations, rules, and interfaces

The initial report may not make that scope clear. An event described as a wrong answer, an unexpected score, or an inappropriate recommendation could reflect more than just the model.

Why an AI model is not the entire AI system

An AI model generates an output from data. An AI system encompasses the broader environment in which the model operates and the processes by which its output is delivered and used.

Consider a customer-support application powered by a large language model. The response may be influenced by:

•   Information retrieved from company systems
•   Instructions provided to the model
•   Filters or safeguards applied before or after generation
•   Product configurations selected by the organization
•   The interface used by an employee or customer
•   Human review before the response is used
•   Third-party integrations

Investigating only the underlying model could leave important causes and evidence unexplored. Distinguishing the model from the complete system helps responders determine what influenced the outcome, who holds relevant information, and where records can be found.

What should initial AI incident intake capture?

Initial intake should not recreate an entire AI inventory. It should capture enough information to identify the system, route the incident, locate records, and begin an investigation:

•   System, product, or feature name
•   Provider, developer, or internal owner
•   Version or configuration, if known
•   Task being performed when the event occurred
•   Related product, service, or business process
•   Time and location of the event
•   Existing AI inventory or risk record, when available

When an organization maintains an AI inventory or uses an AI risk management solution, such as RadarFirst AI Risk, the incident record should be linked to the existing system record. That connection can give responders access to ownership, configuration, risk, and governance information without asking the reporter to reconstruct it.

Early information will often be incomplete. RadarFirst AIM creates an initial incident record that teams can refine as the investigation produces additional facts.

Question 2: What was the organization’s relationship to the AI system?

An organization’s relationship to the system helps responders determine who may hold relevant information, which records and controls are available, and which internal or external stakeholders should participate.

A system developer may have access to design, training, testing, and evaluation records. An organization operating a third-party system may control its configuration, access, and operating environment. An organization affected by someone else’s system may have limited visibility into either. These differences shape the operational response and may also be relevant to a separate legal or regulatory analysis.

RadarFirst AIM uses five relationship categories to support consistent intake and response. The categories do not, by themselves, establish a legally defined role, obligation, or responsibility under a particular regulation.

Developed or provided the system

The organization created, designed, trained, substantially modified, branded, sold, licensed, or otherwise supplied the system for use by others.

•   Developed the complete system internally
•   Offers an AI-enabled product or service
•   Makes a system available under its own name or brand
•   Substantially modifies a system before providing it to others

Deployed or operated the system

The organization put the system into operation or managed it within a product, service, infrastructure environment, or business process.

•   Configured a third-party system
•   Integrated the system into a customer-facing product or internal workflow
•   Determined when, where, or why the system would be used
•   Managed access, monitoring, maintenance, or operational controls

Used the system or its output

The organization or its personnel interacted with the system or relied on its output without necessarily deploying or operating it.

•   An employee used a generative AI tool to draft a document
•   An analyst relied on a third-party risk score
•   A clinician reviewed an AI-generated recommendation
•   A team used AI-generated content in a customer communication

Supplied a component, model, or data

The organization contributed something used to build, train, test, configure, or operate the AI system without providing the complete system.

•   A foundation or specialized model
•   Training, testing, validation, or operational data
•   Software libraries, APIs, sensors, or technical components
•   Data-labeling, model-tuning, evaluation, or related services

Was affected by another organization’s system

A system controlled or used by another organization affected the reporting organization, its employees, its customers, or its operations.

•   A vendor’s AI system disrupted a relied-upon service
•   An external system made an inaccurate decision about an employee or customer
•   AI-generated content falsely referred to the organization
•   Another party’s system caused security, financial, or operational consequences

Why one organization may have multiple relationships

AI systems rarely move along a simple path from one developer to one user. A single organization might provide data to a vendor, configure the vendor’s system, operate it within an internal workflow, and rely on its outputs. Its relationship may also change as a system moves from development to deployment.

Capturing every materially relevant relationship helps prevent gaps in ownership, evidence collection, stakeholder involvement, and regulatory analysis.

How structured intake supports AI incident response

AI incidents rarely arrive with complete information. A report may describe an unexpected output without identifying the configuration that produced it. It may name a third party without explaining how the organization was connected to the system. It may describe harm without clarifying whether the organization developed, operated, used, supplied part of, or was affected by the technology.

Structured intake gives teams a reliable way to begin. By identifying the AI system and the organization’s relationship to it, responders can:

•   Route the matter to the appropriate owners
•   Locate relevant technical and business records
•   Identify missing information
•   Engage the right internal and external stakeholders
•   Maintain a consistent record as the investigation develops

Those two questions do not resolve the incident. They create the clarity and continuity needed to move from an incomplete report toward a timely, explainable, and defensible outcome.

Build a consistent, defensible AI incident process

Bring structure and continuity to AI incident response. See how RadarFirst AI Incident Management helps teams capture essential facts, coordinate the right stakeholders, and maintain a defensible record from the initial report through to the outcome.