Example artifact generated by Azrivo — a Plan-mode deliverable from a generic business scenario. AI-generated draft; verify before use. See the run →

AI Readiness Gate

Every candidate where the proposed solution involves AI/LLM tooling must clear this gate before entering design. Six dimensions. Pass / Conditional / Fail. No exceptions.

When to use this gate: Apply after the process has passed the intake triage and scored well enough on the Evaluation Criteria (Step 2) to be a viable candidate — and the solution approach proposed involves generative AI, LLMs, or any model whose output is probabilistic rather than deterministic. RPA-only, deterministic rule engines, and classic workflow automation skip this gate.

Gate Status: INCOMPLETE

Green: 0 Yellow: 0 Red: 0

Answer all questions across all six dimensions to receive a gate determination.

Dimension 1 of 6 —

Data Sensitivity & Exposure

What data does the AI touch, and where does it go? The core concern is whether sensitive data leaves your control boundary or enters a model provider's environment without adequate contractual, technical, or regulatory safeguards.

Q1. What is the highest classification of data the AI will process?

Non-sensitive internal data (operational metrics, public docs, synthetic)

Internal proprietary / confidential — but not personal or regulated

PII, PHI, PCI-DSS, or similarly regulated personal/financial data

Q2. Where will the data be processed — i.e., where does the model run?

Self-hosted / on-prem / private cloud — data never leaves our environment

Vendor API with a signed DPA/BAA and zero-retention / no-training terms

Vendor API without data-processing agreement; or data may be used for model training

Q3. Can the data be masked, anonymized, or pseudonymized before the AI sees it?

Yes — fully anonymized or the AI doesn't need identifiable data to function

Partially — PII can be masked but context loss may degrade output quality

No — the task inherently requires raw sensitive data (e.g., clinical notes, customer PII)

Dimension 2 of 6 —

Hallucination Tolerance & Blast Radius

LLM output is probabilistic, not deterministic. The question is: when the model hallucinates, who catches it, and what breaks? This dimension measures the cost of being wrong and whether a human stands between the AI and the real world.

Q4. Is a human reviewing the AI's output before it takes any consequential action?

Yes — human-in-the-loop for every output; AI is advisory only

Partial — sampled review, or review only on low-confidence outputs

No — AI output is acted on automatically (straight-through processing)

Q5. What is the blast radius of a single hallucinated output?

Internal only — error causes rework or annoyance, nothing leaves the building

Customer/vendor-facing — error reaches an external party but is correctable

Financial, regulatory, or safety impact — error triggers payment, filing, or harm

Q6. Is the output verifiable — i.e., can correctness be cheaply and reliably checked?

Yes — output is structured (classification, extraction, yes/no) and can be programmatically validated

Partially — output is semi-structured; human spot-check can catch gross errors

No — output is free-text narrative or creative; correctness is subjective

Dimension 3 of 6 —

Bias & Fairness Exposure

Does the AI's output affect people in consequential ways? If the model encodes a bias — from training data or prompt design — who gets hurt and how badly? This dimension separates "the AI summarizes meeting notes" from "the AI screens job applicants."

Q7. Does the AI's output directly or indirectly affect decisions about people?

No — output is about documents, data, systems, or processes, not people

Indirectly — output informs a human decision-maker about people (e.g., summary for a manager)

Directly — AI output is a factor in hiring, credit, benefits, access, pricing, or sanctions decisions

Q8. Could the AI's output disadvantage a group with protected characteristics — even unintentionally?

No — the task domain has no plausible connection to protected characteristics

Possible — domain touches demographics indirectly; bias testing is warranted

Likely — the use case has known bias risks (NLU on dialect, resume screening, credit models)

Q9. Is there a bias monitoring and mitigation plan for this use case?

Yes — defined metrics, regular audits, and a named owner for fairness

Partial — aware of the concern but no formal plan yet

No — bias monitoring has not been considered for this use case

Dimension 4 of 6 —

Explainability & Auditability

Can a regulator, auditor, or non-technical stakeholder understand why the system produced a given output? Where explainability is legally required, a black-box LLM answer is not sufficient — you need an explainability layer, a deterministic fallback, or a different approach.

Q10. Is there a legal or regulatory requirement to explain the AI's output?

No — no right-to-explanation, no regulatory requirement for this process

Desirable but not mandatory — internal policy or stakeholder expectation, not law

Yes — GDPR Art. 22, ECOA, FCRA, or sector-specific regulation requires explainability

Q11. Can the proposed AI approach produce an auditable decision trail?

Yes — prompt, context, output, and confidence scores all logged immutably

Partially — some inputs/outputs logged but not a complete reconstruction

No — the AI path is a black box; no plan to log the decision journey

Q12. Is there a non-AI fallback that can produce the same outcome — for audit or when the AI is unavailable?

Yes — deterministic rules engine or manual process can produce equivalent output

Partial — fallback exists but is slower, lower-quality, or covers only the happy path

No — if the AI is unavailable the process stops; no alternative exists

Dimension 5 of 6 —

Model Sourcing & Vendor Constraints

Where does the model come from, who controls it, and what constraints bind it? This covers data residency, jurisdiction, IP terms, vendor lock-in, and the build-vs-buy decision for the model itself.

Q13. What is the proposed model deployment model?

Self-hosted open model — we control the runtime, data never leaves our infra

Vendor-hosted with enterprise terms — dedicated tenant, data isolation, contractual safeguards

Consumer-grade or shared-tenant vendor API — no enterprise terms, data may be logged

Q14. Do data residency or jurisdictional requirements constrain where the model can run?

No — no data residency or jurisdictional restrictions apply

Yes but manageable — vendor offers in-region deployment or we can self-host

Yes and blocking — data must stay in jurisdiction but no compliant model option exists

Q15. Has vendor due diligence been completed — security review, IP terms, SLA, exit plan?

Yes — vendor is pre-approved, or this is a self-hosted model (no vendor)

In progress — legal/security review underway but not yet signed off

Not started — vendor selection is preliminary; no security or legal review conducted

Dimension 6 of 6 —

AI Governance & Policy Compliance

Does the organization have an AI acceptable-use policy, and does this use case comply with it? This dimension catches the "nobody asked legal" scenario — the automation team builds something useful that quietly violates a policy nobody knew existed.

Q16. Does the organization have a formal AI acceptable-use policy or governance framework?

Yes — published policy with a review/approval process for new AI use cases

Partial — guidelines exist but no formal governance process or approval workflow

No — no AI-use policy exists in the organization

Q17. Has legal / compliance / infosec reviewed this specific use case for AI deployment?

Yes — reviewed and approved for AI use

Not yet — review is scheduled but not completed

No — legal/compliance is unaware this use case is being considered for AI

Q18. Is there an AI governance body (council, board, steering committee) that must approve AI deployments — and has it been engaged?

Yes — engaged and pre-aligned; or no governance body exists and policy allows CoE-led approval

Body exists but has not been briefed on this use case yet

Body exists, requires approval, and hasn't been engaged — project would be blocked at approval stage

If no governance body exists, select the green option (the CoE is the de facto approver). If one exists and mandates approval, engaging it is a prerequisite.

Integration with the broader framework: This gate feeds into Step 2's Risk Safety dimension. A process that scores 1–2 on Risk Safety (Step 2) and also FAILs this gate is a strong signal for deterministic-only automation or deferral. Processes that PASS this gate proceed to the AI solution design track in Step 4. CONDITIONAL processes proceed to design but carry a list of guardrail conditions that must be satisfied before go-live — see the routing table below. This gate should be re-run at design completion (did the design actually satisfy the conditions?) and again post-deployment (did reality match the assessment?).

Fictional example artifact generated by Azrivo (azrivo.com) from a generic business scenario, to show what a Plan-mode run produces. Not a real company deliverable; AI-generated — treat as a reviewable first draft.