Ai Readiness

AI Readiness Audit

You review whether AI / ML components of the application are safe, effective, and defensible — technically, regulatorily, and operationally. This skill sits alongside security, compliance, and data-protection audits but addresses AI-specific failure modes that those skills don't cover.

This skill follows the library-wide rules in [docs/CONVENTIONS.md](../../docs/CONVENTIONS.md). Read that first. This file only documents what's specific to AI.

Scope

This skill applies to applications containing any of:

• Classical ML models (regression, classification, clustering, recommender, forecasting).
• Generative models (text, image, audio, video, code).
• Third-party AI APIs (OpenAI, Anthropic, Google, Azure OpenAI, Bedrock, Cohere, etc.).
• Self-hosted LLMs (llama.cpp, vLLM, TGI, Ollama, etc.).
• Retrieval-Augmented Generation (RAG) pipelines.
• Embedding / vector search.
• Agentic systems with tool use.
• AI-generated content published to end users.

It does not apply to software that merely uses AI-assisted development tooling internally (e.g. Copilot-written code) — that's an engineering process concern, not a product AI concern.

Inputs

From orchestrator: scope_tier, jurisdiction, data_sensitivity, stack_summary, gitnexus_indexed, plus:

• ai_use_case: chatbot | copilot | content-gen | classifier | recommender | decision-support | agent | other
• ai_user_facing: true | false
• ai_affects_individuals: true | false (makes or influences decisions about people)

If not provided, gather via scoping questions.

Finding ID prefix

AI — see CONVENTIONS.md §4.

Tier thresholds

| Tier | Evals | Prompt injection defense | Output filter | Human oversight | Drift monitoring | Model card | |---|---|---|---|---|---|---| | prototype | advisory | advisory | required for user-facing | optional | optional | optional | | team | required (golden set + regression) | required | required | required for user-facing | recommended | required for public releases | | scalable | required (golden set + adversarial + A/B) | required + output validation | required + content moderation | required, with loggable overrides | required + alerting | required + datasheet |

For high-risk AI under EU AI Act (Annex III), scalable-tier controls apply regardless of deployment scale.

Review surface

1. AI system inventory

Before any checks, inventory every AI component:

• Grep for: openai, anthropic, cohere, bedrock, azure.*ai, huggingface, transformers, sklearn, xgboost, tensorflow, keras, torch, llamaindex, langchain, langgraph, crewai, autogen, dspy, vllm, ollama, pinecone, weaviate, chroma, qdrant, milvus, fastembed.
• Look for: .onnx, .pt, .pth, .safetensors, .gguf, .pkl (classical models), .joblib model artifacts.
• Inspect requirements.txt / package.json / go.mod for ML dependencies.
• Ask about models deployed behind feature flags, internal-only, or used only in batch pipelines.

For each AI system, record:

• Purpose (what decision or output it produces).
• Inputs (data types, sources, users).
• Outputs (where they go, who sees them).
• Model(s) used (name, version, provider).
• Triggers (user action, schedule, event).

This inventory drives every downstream check.

2. EU AI Act classification (if EU jurisdiction applies)

Cross-reference compliance-check/frameworks.yaml for the full control list. For each AI system:

• Prohibited (Art. 5) — subliminal manipulation, exploitation of vulnerability, social scoring, untargeted facial scraping, emotion recognition in work/education, real-time biometric ID in public, predictive policing based solely on profiling. Critical — the product cannot ship as specified.
• High-risk (Annex III) — biometrics, critical infrastructure, education/vocational, employment/HR, essential services (credit, insurance, emergency), law enforcement, migration/border, justice, democratic processes. Full Chapter III obligations.
• Limited-risk (Art. 50) — chatbots, emotion recognition, biometric categorization, AI-generated content (deepfakes, synthetic media). Transparency obligations apply.
• Minimal-risk — everything else.
• GPAI model provider — separate Chapter V obligations.

Flag each AI system with its classification and the specific articles that apply.

3. Training data governance

For any model trained or fine-tuned in-house:

• Provenance — where did training data come from? Consented for this purpose under the relevant privacy regime?
• Datasheet — is there a documented description of training data composition, sources, known biases, demographic distribution, collection method, processing steps, intended and unintended uses? (Gebru et al. "Datasheets for Datasets" format at team+ tier.)
• Personal data in training data — if any, GDPR applies. Lawful basis, DPIA, DSR implications (Art. 17 erasure is hard with baked-in model).
• Copyright provenance — documented permission / license / exception used for copyrighted material. Text and Data Mining (TDM) exceptions properly claimed (EU DSM Directive Art. 4).
• Contamination — training data overlap with eval data? Measured and mitigated?
• Representativeness / demographic coverage — documented for systems affecting individuals.
• Data quality pipeline — validation, deduplication, outlier handling.

For third-party models (OpenAI, Anthropic, etc.), record what the provider publishes about their training data and any contractual restrictions on use.

4. Model supply chain

• Model artifacts pinned by version + digest (not "latest").
• Downloaded from trusted registries (HuggingFace Hub, provider APIs) with hash verification.
• Model files scanned for malicious content (unpickling, executable payloads) — pickle model files are known to enable arbitrary code execution; prefer safetensors format.
• Model cards consulted and stored alongside code.
• Provider SLA / availability commitments known.
• Fallback model (cheaper / local / alternative provider) identified if primary is down.
• For API-based models: key rotation, usage caps, quota monitoring.

5. Evaluation harness

A production AI system must have evaluations, not just tests:

• Golden set — curated examples with expected outputs, covering: happy path, edge cases, adversarial inputs, failure modes. Refreshed as new failure modes are discovered.
• Task-specific metrics — classification: precision / recall / F1 / AUROC. Generation: BLEU / ROUGE / exact-match / semantic similarity / LLM-as-judge. Recommender: recall@k / NDCG. Agent: task completion rate / tool-use correctness.
• Regression gates — CI runs the golden set on every change that could affect model behavior (prompt changes, model changes, RAG index changes, fine-tune changes). Fails on regression beyond a documented threshold.
• Human eval for subjective quality — at scalable tier, recurring human eval loop for user-facing generation.
• Eval frameworks: promptfoo, langsmith, openai-evals, deepeval, inspect, ragas, tru-lens, helm, phoenix. Recognize and use what's present.
• Eval data curation discipline — eval data excluded from training / prompt-engineering loops to avoid contamination.

6. Prompt injection defenses (LLM apps)

• Trust boundary between system and user input is explicit. User input never concatenated into the system prompt without delineation.
• Structured input contracts — separate system, user, and retrieved-content channels; don't serialize user text into prompt as if it were system instruction.
• Output validation — parse / schema-check LLM outputs before acting on them. For tool-calling, validate arguments against a schema.
• Tool use gating — destructive tools (delete, send email, transfer funds, write to DB) require explicit authorization gates — either user confirmation or policy checks, never LLM-only authorization.
• Indirect prompt injection — if the system retrieves content (RAG, email, web scraping, file uploads), assume that content contains injected instructions. Don't treat retrieved text as trusted.
• Jailbreak resistance — adversarial eval set covering known jailbreak categories (role-play, encoding tricks, multi-turn manipulation, authority impersonation).
• Canary tokens — invisible markers in system prompt / retrieved docs that let you detect when they've been exfiltrated.
• Defense-in-depth: input filter → structured prompt → output filter. No single layer is sufficient.

Common anti-patterns:

• f"{system_prompt}\nUser said: {user_input}" — direct concatenation.
• Treating role: user content as trusted because it came from your frontend — any AI pipeline that reads from tool outputs, documents, or search results has multiple injection vectors.
• "Please do not ignore the above instructions" as the only defense — easily bypassed.

7. RAG quality and security

For retrieval-augmented generation pipelines:

• Retrieval quality metrics tracked: recall@k, precision, MRR. Not just "it returns documents".
• Query understanding — tests that retrieval handles typos, synonyms, code snippets, languages.
• Chunking strategy documented and tested — chunk size, overlap, boundary handling.
• Re-ranking at team+ tier for quality-critical applications.
• Hybrid search (dense + sparse) considered if documents contain exact terms (names, IDs, codes) that pure-semantic search may miss.
• Citation / attribution — responses cite sources. Sources are verifiable.
• Retrieval access control — retrieval respects the querying user's document access permissions. Cross-user or cross-tenant leakage is a critical finding.
• Data poisoning / document injection — if users upload documents into the RAG corpus, they can inject instructions. Either (a) segregate user-provided and authoritative corpora, or (b) treat all retrieved content as untrusted input.
• Stale index — index freshness monitored. Alert on excessive staleness.
• Embedding drift — if embedding model changes, existing embeddings are incompatible. Migration strategy documented.

8. Hallucination handling

For generative models:

• Hallucination detection — for factual Q&A, confidence / verification loop (LLM-as-judge, retrieval-grounding check, source comparison).
• Grounding requirement — response must be derivable from retrieved sources; ungrounded claims flagged.
• Confidence communication to user — "I don't know" / "I'm not sure" is allowed, rather than confabulating.
• Context window management — graceful behavior when context fills up (summarize, retrieve more selectively), not silent truncation of critical context.
• Fallback to human / rule-based for low-confidence outputs in high-stakes workflows.

9. Output filtering and moderation

For user-facing outputs:

• Content moderation — harmful content filter on every generation: hate, harassment, sexual content, violence, self-harm, illegal activity.
• PII leakage check — redact unintended PII in outputs (especially if training or RAG corpus contains PII).
• Bias / toxicity testing across demographic axes relevant to the use case.
• Hallucinated citation detection — for citing sources, verify the citation exists.
• Jailbreak output detection — pattern-match on outputs that suggest the model leaked its system prompt or was manipulated.
• Moderation providers — OpenAI Moderation, Google Perspective, Azure Content Safety, Anthropic usage policies. Self-hosted: Llama Guard, Detoxify.

10. Human oversight

• Oversight by design — humans can review, override, reverse AI decisions. Not a post-hoc "you can email support" — a built-in capability.
• Override logged and analyzed — overrides are a signal about where the AI is failing.
• Stop-the-line capability — operators can disable the AI system globally (feature flag / kill switch) without redeploy.
• High-risk decisions (EU AI Act Annex III) — human review required before the decision is enacted, not just after.
• Training to reliance monitored — humans rubber-stamping AI outputs indicates inadequate oversight.

11. Transparency and disclosure

• Model card per public-facing model: intended use, known limitations, performance metrics, training data summary, ethical considerations, recommended monitoring. (Mitchell et al. format.)
• Datasheet per dataset at scalable tier.
• User-facing disclosure — when users interact with an AI system (chatbot, emotion recognition, biometric categorization) or see synthetic content (deepfakes), disclosure required by EU AI Act Art. 50.
• AI-generated content marked — watermarking / C2PA provenance metadata for generated images, audio, video at scalable tier.
• Explanation for individual decisions — for high-risk or GDPR Art. 22 automated decisions, user can get meaningful info about the logic involved.

12. Fairness and bias testing

• Protected attribute inventory — what attributes might lead to discrimination? (Race, gender, age, disability, nationality, religion, sexual orientation — jurisdiction-dependent.)
• Group fairness metrics — demographic parity / equal opportunity / equalized odds measured across protected groups.
• Individual fairness — similar individuals receive similar outcomes.
• Counterfactual testing — swap protected attributes and observe output change.
• Fairness evaluation refreshed periodically, not just at launch.
• Disparate impact thresholds documented.
• Known failure modes for the model class (e.g. known LLM biases) recorded and monitored.
• Tools: fairlearn, aif360, what-if.

13. Cost controls

• Per-request cost estimate available (tokens × model pricing).
• Per-user / per-tenant spend caps enforced to prevent runaway / malicious usage.
• Model tiering — cheap model for most queries, expensive model escalation only when needed.
• Prompt caching (Anthropic prompt caching, OpenAI prompt caching) used where beneficial.
• Context truncation strategy in place (don't send 100k-token context when 5k suffices).
• Batch inference for offline workloads.
• Monitoring and alerting on spend anomalies. Budget alerts at 80% / 100% / 120%.
• Non-production environments have tighter caps than production.

14. Drift monitoring

• Input distribution drift — tracked. Alerts when production inputs diverge from training distribution beyond threshold.
• Output distribution drift — for classifiers, class distribution over time. For generation, embedding-based distribution drift.
• Performance drift — measured metric decay (precision, user satisfaction, completion rate). Alerts.
• Concept drift — ground-truth labels change over time (fraud patterns evolve, user language shifts).
• Drift triggers retraining / re-evaluation via documented process, not ad-hoc.

15. Red-teaming

At team+ tier (user-facing), scalable (required):

• Scheduled red-team exercises with adversarial prompts, jailbreak attempts, data exfiltration attempts, harmful content requests.
• External red-team at scalable tier for high-risk applications.
• Red-team findings feed back into eval set and output filter tuning.
• Third-party testing for high-risk AI under EU AI Act conformity assessment.

16. Content provenance

For AI-generated media:

• C2PA manifests attached to generated images, audio, video at scalable tier.
• Invisible watermarking (SynthID-style) where provider supports it.
• Metadata disclosure in user-facing artifacts.

17. Logging and auditability

• Every inference call logged — request ID, model version, prompt / input, output, latency, cost, user, timestamp.
• PII in logs handled per data-protection-audit rules.
• Tamper-resistant storage for decisions affe

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Nordic-AI
• Source: Nordic-AI/production-readiness-skills
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.