patkusch

agent-failure-diagnosis

Diagnose why an AI agent behaved badly, using operationalised criteria that two independent reviewers can apply to the same evidence and reach the same answer. Use this whenever someone describes an agent that misbehaved, went off track, did something unexpected, ignored instructions, made things up, went beyond its scope, got stuck in a loop, lied about what it did, or "went rogue" — and whenever reviewing agent traces, logs, or transcripts to work out what went wrong. Use it for post-incident analysis, for design reviews asking "how could this fail?", and when someone needs to classify agent failures consistently enough to spot patterns across many incidents. Reach for this even when the user just wants an explanation rather than a formal report, because the classification is what makes the explanation defensible later.

ai-incident-triage

Triage an AI or agent incident — classify what failed, establish severity and reach, determine whether external reporting obligations are engaged, and produce the incident record. Use this whenever an AI system or agent caused a problem, produced a harmful or wrong output that reached someone, took an action it should not have, leaked data, or failed in production; whenever someone says "the agent did something bad", "we had an AI incident", "this model gave a customer the wrong answer", or asks whether an AI failure needs reporting to a regulator. Use it for near misses too, since those carry the same lessons at a fraction of the cost. Reach for this before writing any incident summary or RCA involving an AI system, because the classification and the reporting-clock assessment need to happen early — reporting deadlines under the EU AI Act and DORA run from awareness, not from the end of your investigation.

ai-system-intake

Create or update the governance record for an AI system or agent — the shared artefact every other Remit assessment reads from. Use this whenever someone describes an AI system, model, agent, copilot, chatbot, or automation and there is any governance, risk, compliance, audit, or regulatory dimension to the conversation; whenever a new AI use case is proposed, onboarded, inventoried, or registered; whenever someone asks "do we need to assess this?", "is this in scope for the AI Act?", or "what AI do we have?"; and always as the first step before any EU AI Act, NIST AI RMF, ISO 42001, DORA, or autonomy assessment, because those skills need a system record to work from. Use it even when the user has not asked for an inventory — if they are describing an AI system that will touch real users or real decisions, the record is what makes everything downstream possible.

eu-ai-act-triage

Classify an AI system under the EU AI Act — prohibited, high-risk, transparency-only, or minimal — establish whether the organisation is provider or deployer, and produce the resulting obligation set with dates. Use this whenever the EU AI Act, AI Act, Regulation 2024/1689, Annex III, high-risk AI, GPAI, or AI conformity assessment comes up; whenever someone asks "is this high-risk?", "does the AI Act apply to us?", "what do we have to do for this AI system?", or "are we a provider or a deployer?"; and whenever an AI system touches employment, recruitment, credit or creditworthiness, insurance pricing, education, essential public or private services, biometrics, emotion recognition, critical infrastructure, law enforcement, migration, or the administration of justice, since those are the Annex III areas where high-risk classification is most often missed. Also use it when an organisation is fine-tuning, rebranding, or materially modifying a third-party AI system, because that can silently convert a deployer i

iso-42001-soa

Build or review an ISO/IEC 42001 AI management system — clause conformity and the Annex A Statement of Applicability with justified inclusions and exclusions. Use this whenever ISO 42001, ISO/IEC 42001, AIMS, AI management system, Statement of Applicability, or AI certification comes up; whenever an organisation is preparing for certification, responding to a customer or procurement requirement for certified AI governance, or extending an existing ISO 27001 management system to cover AI; and whenever someone asks "what do we need for ISO 42001?", "which AI controls apply to us?", or "how do we justify excluding a control?". Also use it when an organisation already runs ISO 27001 or 9001 and wants to know what genuinely differs for AI, since most of the management-system machinery is reusable and only the AI-specific controls are new.

nist-ai-rmf-assessment

Run a gap assessment against the NIST AI Risk Management Framework — GOVERN, MAP, MEASURE, MANAGE — and produce prioritised findings with evidence. Use this whenever NIST AI RMF, AI RMF 1.0, the AI risk management framework, trustworthy AI characteristics, or the Generative AI Profile (NIST AI 600-1) comes up; whenever a US-based or federally-connected organisation needs an AI risk assessment; whenever someone asks "how mature is our AI governance?", "what's our AI risk posture?", or "where are the gaps in how we manage AI?"; and whenever a customer, regulator, insurer, or procurement process asks an organisation to demonstrate AI risk management against a recognised framework. Also use it when an organisation wants a voluntary framework to structure AI governance and has not chosen one, since AI RMF is the most common starting point and maps onward to ISO 42001 and the EU AI Act.