Capture the concern without waiting for certainty.
Record what happened, when it was observed, which system and use were involved and who may be affected. Separate confirmed facts from assumptions. A reporter should not have to determine the legal category before telling the responsible team about a potentially serious problem.
Avoid copying unnecessary sensitive information into broad notifications. Identify where relevant evidence is held and who is authorised to preserve and review it.
Assign containment and decision authority.
Identify who can restrict or suspend use, contact the supplier and coordinate the investigation. Keep operational safety, privacy and security teams involved where their responsibilities are relevant. A communication plan should name primary and alternate contacts.
Record the reason for interim actions and the conditions for resuming use. A change in a ticket status alone should not authorise an operational restart.
Assess the applicable reporting route.
The AI Act contains role-specific incident and information duties, including relevant deployer responsibilities in Article 26. Other frameworks or contracts may also require action. Have the responsible specialists identify the trigger, recipient and deadline for each applicable duty.
Do not assume every report follows the same clock or that an internal ticket satisfies an external notification requirement. Record the decisions and any notifications made through authorised channels.
Close with evidence and follow-up.
An incident record should connect the findings to corrective actions, verification and any change to the earlier approval. Consider whether similar use cases or shared suppliers are affected. Preserve unresolved questions and explain who will review them.
- A factual chronology and affected-system reference.
- Containment, investigation and reporting decisions.
- Action owners and evidence of completion.
- Lessons applied to monitoring, instructions or approval conditions.