1.1 EU AI Act (2024): High-Risk Obligations and GPAI Requirements
The EU AI Act entered into force in August 2024, with phased application periods. For procurement teams, the operative question is whether your intended deployment falls under Annex III β the high-risk AI system categories. Agents that touch any of the following are presumptively high-risk:
- HR decisions: CV screening, interview scheduling, performance evaluation, termination recommendations.
- Credit scoring: creditworthiness assessment, insurance risk scoring, loan origination support.
- Law enforcement: predictive policing, criminal risk scoring, evidence analysis.
- Critical infrastructure: energy grid management, water systems, traffic control.
- Healthcare: diagnostic support, treatment recommendation, patient triage.
- Education: student evaluation, admission scoring, learning assessment.
High-risk classification triggers the full conformity assessment regime under Article 9. In practice, this means your vendor must provide:
- Technical documentation (Article 11): architecture, training data descriptions, intended purpose, performance metrics, limitations, known risks.
- Logging and audit trails (Article 12): automatic logging of all operations sufficient to identify inputs, outputs, and operator-level interventions. Logs must be retained for the system's operational lifetime, minimum 6 months.
- Human oversight mechanisms (Article 14): the system must enable human monitoring, ability to intervene, ability to override, and ability to halt. This must be technically enforced, not just policy-stated.
- Transparency to deployers (Article 13): vendors must provide plain-language descriptions of agent capabilities, limitations, accuracy expectations, and foreseeable misuse scenarios.
- Post-market monitoring (Article 61): continuous collection of performance data post-deployment, with incident reporting obligations for serious malfunctions.
General-Purpose AI (GPAI) models serving as agent foundations trigger Article 53 requirements. If your agent is built on a foundation model (GPT-4, Claude, Gemini), the foundation model provider must disclose: training methodology, training data sources and provenance, energy consumption during training, evaluation results on standardized benchmarks, and cybersecurity measures. If the foundation model has "systemic risk" (threshold: 10^25 FLOP training compute), the obligations extend to adversarial testing, incident reporting to the EU AI Office, and cybersecurity protections.
Enforcement bite: Fines up to β¬35 million or 7% of global annual turnover for high-risk violations. Fines up to β¬15 million or 3% for GPAI violations. Fines up to β¬7.5 million for providing incorrect information to authorities.
Procurement implication: Before signing any AI agent contract for a Annex III use case, require written confirmation from the vendor that they have completed or are completing conformity assessment, can provide Article 11 technical documentation, have logging mechanisms meeting Article 12 requirements, and will provide Article 61 post-market monitoring data to your organization.
1.2 NIST AI Risk Management Framework (2023): The Four Functions
NIST AI RMF is the US federal government's framework for managing AI risk, and it has become the de facto standard for enterprise AI governance. Published in January 2023, it organizes AI risk management into four functions:
GOVERN: Establishing accountability structures, policies, and organizational culture for responsible AI. GOVERN 1.1 requires documented accountability structures for AI β who is responsible for AI system behavior, who can authorize deployment, who can authorize suspension. For procurement, this means identifying the internal owner before signing, not after.
MAP: Identifying AI-related risks in the context of the specific deployment. MAP 1.1 requires categorizing the AI system's intended and unintended uses. MAP 5.1 requires assessing potential harms to end users, third parties, and society. For agent procurement, this means running a harm assessment specific to your use case β not accepting the vendor's generic risk documentation.
MEASURE: Quantifying and tracking AI risks through testing, monitoring, and evaluation. MEASURE 2.5 specifically requires adversarial testing β evaluating the AI system under conditions designed to elicit failures, including prompt injection, context manipulation, and goal-misspecification attacks. This is not optional for high-consequence deployments.
MANAGE: Responding to and recovering from identified AI risks. MANAGE 2.2 requires documented response plans for AI incidents. MANAGE 4.1 requires mechanisms for decommissioning AI systems when risks exceed acceptable thresholds.
SP 800-218A (Secure Software Development Practices for AI) adds secure development guidance: model supply chain verification, training data integrity, adversarial robustness requirements, and output filtering controls.
Procurement implication: Require vendors to map their product against NIST AI RMF functions. A credible answer includes: GOVERN documentation (accountability structure, policies), MAP artifacts (risk catalog for your deployment context), MEASURE evidence (evaluation methodology, adversarial test results), and MANAGE procedures (incident response, decommissioning process).
1.3 ISO/IEC 42001 (2023): AI Management System Standard
ISO/IEC 42001 is the first international standard for AI management systems, published in December 2023. It follows the ISO Annex SL high-level structure (same as ISO 27001, ISO 9001), making it integratable with existing management system certifications.
For AI agent procurement, the relevant clauses include:
- Clause 6.1.2 (AI impact assessment): Organizations must conduct impact assessments for AI systems before deployment. These must identify intended use, affected parties, potential harms, and mitigation controls. Require vendors to provide their impact assessment documentation.
- Clause 8.4 (AI system life cycle): Defines requirements across development, testing, deployment, monitoring, and decommissioning. Procurement review should cover all phases, not just pre-deployment testing.
- Clause 9.1 (Monitoring and measurement): Organizations must establish criteria for evaluating AI system performance, measure against those criteria, and analyze results. For buyers, this translates to requiring vendors to share their monitoring methodology and results.
- Clause 10.1 (Continual improvement): AI systems must have mechanisms for learning from operational experience and improving over time.
Annex A provides an AI-specific control set including: AI policy, AI roles and responsibilities, AI impact assessment processes, data governance for AI, AI system documentation, and AI incident management.
Procurement implication: Ask vendors if they are ISO/IEC 42001 certified or working toward certification. If not, ask how they address the key control areas from Annex A. A credible answer demonstrates the management system exists β even without formal certification.
1.4 SOC 2 Type II: Processing Integrity for AI Agents
SOC 2 Type II reports are now standard in AI vendor RFPs. The five Trust Service Criteria (TSC) are Security, Availability, Confidentiality, Processing Integrity, and Privacy. For AI agents, Processing Integrity (PI) is the critical criterion.
PI criteria require that system processing be complete, valid, accurate, timely, and authorized. For an AI agent, this means:
- PI 1.1: The system processes inputs completely and accurately β no silent data loss, truncation, or hallucinated augmentation.
- PI 1.2: System outputs are distributed to the correct counterparty β no routing errors, no output to unauthorized recipients.
- PI 1.3: System inputs are protected from modification in transit β data integrity controls.
The 2024 AI supplement to the CAIQ (Consensus Assessment Initiative Questionnaire, maintained by the Cloud Security Alliance) adds 47 AI-specific controls across: model governance, training data provenance, output monitoring, bias detection, explainability, and incident response for model failures.
Procurement implication: Require vendors to provide their SOC 2 Type II report covering the Processing Integrity criteria. Review the description of controls and the auditor's exception findings. A report that lists PI controls but has exceptions or qualifications in the testing results is a material red flag.
1.5 Sector-Specific Compliance: HIPAA, DORA, FedRAMP
HIPAA: AI agents accessing protected health information (PHI) must operate under a Business Associate Agreement (BAA). The BAA must address: permitted uses and disclosures of PHI, safeguard requirements (administrative, physical, technical), breach notification obligations, and agent model training data restrictions (PHI cannot be used to train models without patient consent and appropriate authorization). Agents with access to clinical notes, diagnostic data, or treatment records are BAAs by operation of law β not by negotiation.
DORA (Digital Operational Resilience Act, EU): Effective January 2025, DORA requires financial entities in the EU to manage ICT third-party risk. AI agents providing services to EU-regulated financial institutions qualify as ICT third-party service providers and must be: registered in the ICT vendor register, subject to contractual provisions per Article 30 (including audit rights, data location, exit plans, and resilience testing), and included in the institution's ICT continuity plans. DORA fines up to 1% of average daily global turnover per day of non-compliance.
FedRAMP: US government agencies procuring AI agents require FedRAMP authorization. FedRAMP Moderate requires 325 security controls; FedRAMP High requires 421 controls. AI-specific controls are now being added to the FedRAMP baseline under the OMB memo on responsible AI procurement. Vendors without FedRAMP authorization cannot operate in government environments β this is not waivable.
GDPR Article 22: This is the sleeper compliance risk in enterprise AI agent deployments. Article 22 prohibits solely automated decisions that produce legal or similarly significant effects on individuals β unless: explicit consent has been obtained, the decision is necessary for a contract, or EU/member state law authorizes it. For any agent making or contributing to hiring, lending, insurance, or medical decisions, Article 22 creates mandatory requirements for human review, individual rights to contest decisions, and explicit legal basis documentation. Organizations that deploy agentic systems making consequential decisions without satisfying Article 22 are exposed to GDPR enforcement β up to β¬20M or 4% of global annual turnover.
2. The 5-Phase AI Agent Procurement Process
Gartner's 5-phase IT procurement framework (Identify β RFI/RFP β Evaluation β Negotiation β Contract) needs specific adaptations for AI agents. Standard IT procurement misses the behavioral dimension entirely.
Phase 1: Identify and Classify (Weeks 1β2)
Before any vendor contact, classify the intended workflow by consequence level:
| Tier | Description | Examples | Procurement Rigor |
|---|
| Tier 0 | Advisory/informational, zero autonomous action | Research summarization, draft generation | Standard IT vendor review |
| Tier 1 | Recommends actions, human approves all | Contract drafting, lead scoring, scheduling | Enhanced: behavioral pacts, evaluation evidence |
| Tier 2 | Executes low-value actions autonomously | Email sending, calendar booking, data entry | Full: all 15 contract clauses, KPI framework |
| Tier 3 | Executes high-value or irreversible actions | Financial transactions, data deletion, customer commitments | Maximum: + independent red team, escrow, GDPR Article 22 analysis |
For Tier 2 and Tier 3 deployments, complete a pre-procurement harm assessment before issuing any RFI. Document: intended use, potential for misuse, affected parties, maximum foreseeable damage from failure, and applicable regulatory framework.
Output: Tier classification document, harm assessment, applicable regulatory checklist.
Phase 2: RFI and Market Survey (Weeks 2β4)
The RFI stage for AI agents should surface: whether behavioral verification infrastructure exists, what evaluation methodology the vendor uses, how behavioral drift is detected and reported, and what the vendor's incident response track record looks like.
Do not ask vendors to self-certify compliance. Ask for artifacts: evaluation reports, SOC 2 reports, incident post-mortems, and sample audit logs. Vendors who cannot provide artifacts at RFI stage are not production-ready for Tier 2+ deployments.
Output: Shortlist of vendors who can provide evidence artifacts, not just claims.
Phase 3: Deep Evaluation (Weeks 4β8)
This is where most procurement processes are weakest. Standard evaluation tests the agent in a demo environment against prepared scenarios. Production evaluation requires:
- Behavioral baseline testing: run the agent against your own representative workload sample, not the vendor's demo dataset.
- Adversarial testing: minimum 3 sessions (see Section 6 for protocol).
- Integration security review: how does the agent authenticate, what data does it access, where does inference data go, how are credentials managed.
- Score and evaluation review: what does the vendor's trust score or reliability score actually measure, how is it computed, can you reproduce it independently.
Output: Evaluation report with pass/fail against your Tier-appropriate criteria.
Phase 4: Negotiation (Weeks 8β10)
Negotiation for AI agents is substantially different from standard software negotiation. Price is often the least important variable. The critical negotiation items are: behavioral obligations and their consequences, audit rights and scope, incident response SLAs, model substitution notice, and exit provisions.
Vendors who resist behavioral obligations β who push back on pacts, evaluation evidence requirements, or audit access β are signaling that their product cannot sustain the scrutiny. That is material information about product maturity, not a negotiating posture to overcome.
Output: Redlined contract with all 15 clauses addressed.
Phase 5: Contract and Governance Setup (Weeks 10β12)
Contract execution is the beginning of vendor governance, not the end of procurement. Before go-live:
- Instrument all 10 KPIs (see Section 5).
- Schedule quarterly vendor review sessions.
- Designate internal owner responsible for score monitoring.
- Document escalation path if behavioral thresholds are breached.
- Confirm kill switch procedure with operations team.
Output: Live KPI dashboard, governance calendar, owner assignments.
3. The 25 RFP Questions: What to Ask and What Good Answers Look Like
These questions are organized by procurement domain. For each question, the rubric describes what distinguishes a strong answer from a weak one.
3.1 Behavioral Verification and Evaluation (Questions 1β7)
Q1: How are behavioral claims about this agent verified?
Weak answer: "We have an extensive internal QA process and red team before each release."
Strong answer: "We maintain publicly verifiable behavioral pacts that define agent obligations in machine-readable format. Evaluations are run on standardized test suites by our independent jury system [or named third party]. Evaluation reports are available to customers within 48 hours of any major update."
Scoring: 0 points for process claims with no artifacts; 3 points for internal artifacts available on request; 5 points for publicly verifiable pacts with third-party evaluation records.
Q2: What is the agent's composite trust score and how is each dimension weighted?
Weak answer: Score is reported without dimension breakdown, or score is a single vendor-defined metric.
Strong answer: Multi-dimensional score (e.g., accuracy, reliability, safety, security, scope-honesty, latency, cost-efficiency) with explicit weights, fresh evaluation timestamps, and human-readable explanation for each dimension.
Scoring: 0 for single-number score with no decomposition; 3 for multi-dimensional with methodology documented; 5 for multi-dimensional, third-party verified, with decay controls that prevent stale scores from being presented as current.
Q3: How frequently is the agent re-evaluated, and what triggers out-of-cycle evaluation?
Weak answer: "We run evaluations quarterly or when we make significant changes."
Strong answer: Defined re-evaluation cadence (monthly minimum for production agents), explicit triggers for out-of-cycle evaluation (underlying model update, new capability release, incident, customer complaint, score drift >X%), and notification SLA to customers when re-evaluation results are available.
Scoring: 0 for ad-hoc; 2 for calendar-only cadence; 5 for cadence + event-triggered + customer notification SLA.
Q4: Can evaluation results be independently reproduced by the buyer?
Weak answer: "Our evaluation environment uses proprietary infrastructure that can't be replicated externally."
Strong answer: Evaluation methodology is documented in sufficient detail for a technically competent buyer to reproduce. Test prompts and expected outputs are available (with appropriate IP protections). Buyers can run evaluation suites against the production agent using provided tooling.
Scoring: 0 for black-box vendor-only; 3 for methodology documented but not reproducible; 5 for buyer-reproducible with documented test suite.
Q5: What is the agent's observed scope violation rate in production, and how is scope violation detected?
Weak answer: "We haven't observed scope violations in our testing."
Strong answer: Actual production scope violation rate (even if zero, the methodology for measurement must be stated), automated monitoring that flags out-of-scope actions, escalation path when scope violation is detected, and customer notification protocol.
Scoring: 0 for no measurement; 2 for self-reported without methodology; 5 for instrumented monitoring with production data and customer access to logs.
Q6: How does the agent handle ambiguous instructions that could be interpreted to exceed its authorized scope?
Weak answer: "The agent uses its judgment to determine the most helpful interpretation."
Strong answer: Explicit scope boundary enforcement in the agent's instruction set, with documented handling for ambiguous cases (escalate to human, refuse with explanation, request clarification). Audit log entry created for every ambiguous case.
Scoring: 0 for LLM judgment without controls; 3 for documented policy; 5 for technically enforced scope boundaries with audit trail.
Q7: What adversarial tests have been run on this agent, and what were the results?
Weak answer: "We use best practices for AI safety."
Strong answer: Named adversarial test categories run (prompt injection, context manipulation, jailbreak attempts, goal-misspecification), mapped to MITRE ATLAS (at minimum AML.T0040, AML.T0051, AML.T0054), with quantified results (attack success rate, recovery behavior) and remediation evidence for any successful attacks.
Scoring: 0 for vague reference to safety practices; 2 for documented categories without MITRE mapping; 5 for MITRE-mapped with quantified results and third-party attestation.
3.2 Data Handling and Privacy (Questions 8β12)
Q8: Where does inference data (user inputs, agent outputs, context) go, and for how long is it retained?
Weak answer: "Data is handled securely per our privacy policy."
Strong answer: Data flow map showing where inference data is processed (region, provider, sub-processors), retention periods by data category, customer data isolation (is your data used to train shared models?), deletion procedures, and right-to-erasure implementation.
Scoring: 0 for policy reference without specifics; 3 for data flow documented but no sub-processor detail; 5 for complete data flow map with sub-processor list, retention schedule, and customer deletion rights.
Q9: Does the agent's inference infrastructure use customer data for model training?
Weak answer: "We may use anonymized data to improve our models."
Strong answer: Explicit opt-out (or opt-in) controls for training data use, contractual commitment that production inference data will not be used for model training without explicit customer consent, and audit mechanism to verify this commitment.
Scoring: 0 for implicit opt-in; 2 for opt-out available but not default; 5 for explicit opt-in required with contractual commitment and audit mechanism.
Q10: How are agent credentials (API keys, OAuth tokens, database connections) managed and protected?
Weak answer: "Credentials are stored securely in our system."
Strong answer: Credential storage in dedicated secrets management system (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault), encryption at rest (AES-256), in-transit TLS 1.3, access logging for all credential reads, rotation automation, and zero-knowledge architecture (vendor cannot read customer credentials).
Scoring: 0 for "stored securely"; 3 for named secrets manager with encryption; 5 for zero-knowledge architecture with rotation automation and access logs.
Q11: What is the data processing agreement (DPA), and does it cover GDPR and CCPA requirements?
Weak answer: "Our DPA is available on our website."
Strong answer: DPA covers: data processing purposes, sub-processor list, cross-border transfer mechanisms (SCCs for GDPR), data subject rights fulfillment SLAs, breach notification timelines (72 hours for GDPR), data deletion upon termination, and controller/processor designation for each data category.
Scoring: 0 for standard click-through DPA; 3 for customizable DPA; 5 for DPA customizable per deployment with sub-processor disclosure and rights fulfillment SLAs.
Q12: For healthcare deployments: will the vendor sign a HIPAA Business Associate Agreement?
Weak answer: "We can look into that depending on your specific use case."
Strong answer: Standard BAA template available, covers administrative/physical/technical safeguards, specifies PHI use limitations, breach notification procedure (60-day HIPAA requirement), and explicitly restricts PHI from being used in model training or shared inference infrastructure.
Scoring: 0 for no BAA capability; 3 for BAA available but requires custom negotiation; 5 for standard BAA with PHI training restriction explicitly addressed.
3.3 Incident Response and Operational Resilience (Questions 13β18)
Q13: What is the agent's kill switch implementation, and what is the maximum latency to halt?
Weak answer: "Administrators can disable the agent from the dashboard."
Strong answer: Kill switch is a dedicated control path separate from normal agent operations, halt latency is measured and documented (target: <5 seconds for in-flight task suspension, <30 seconds for full halt of all queued tasks), kill switch is accessible to customer administrators without requiring vendor involvement, and kill switch events are audit logged.
Scoring: 0 for dashboard toggle with no latency guarantee; 3 for dedicated control with documented latency; 5 for <5s halt, customer-controlled, audit logged, and tested in last 90 days.
Q14: What is the incident response SLA for behavioral failures?
Weak answer: "Our support team is available 24/7."
Strong answer: Tiered incident classification (P1: agent executing out-of-scope actions or causing data loss; P2: performance degradation >20%; P3: anomalous behavior within bounds), RTO per tier (P1: <15 min detection, <1 hour recovery; P2: <30 min detection, <4 hours recovery), RPO (P1: zero tolerance for data loss from agent actions), root cause analysis report within 5 business days for P1.
Scoring: 0 for availability SLA only; 3 for tiered SLA without behavioral definition; 5 for behavioral incident classification with RTO/RPO and RCA commitment.
Q15: How is behavioral drift detected and what triggers customer notification?
Weak answer: "We monitor our systems continuously."
Strong answer: Behavioral Drift Score (BDS) or equivalent metric computed against baseline, automated alerting when drift exceeds threshold (e.g., >10% deviation from baseline triggers review, >15% triggers customer notification), drift alerts include root cause hypothesis and remediation timeline, customer receives notification within 4 hours of threshold breach.
Scoring: 0 for monitoring without behavioral baseline; 3 for threshold-based alerting; 5 for BDS with tiered alerts, root cause, and customer notification SLA.
Q16: What is the vendor's history of material incidents in the last 24 months?
Weak answer: "We haven't had any significant incidents."
Strong answer: Incident log with dates, classification, customer impact, and resolution. Willingness to provide post-mortem documents under NDA. Zero incidents in a production AI agent vendor is not credible β the question is whether they have the processes to detect and report them.
Scoring: 0 for denial without documentation; 3 for incident list without post-mortems; 5 for incident log with post-mortems showing systematic improvement.
Q17: Can the agent be deployed in a private cloud or on-premises environment?
Weak answer: "We're cloud-only for security reasons."
Strong answer: Deployment options documented (SaaS, private cloud, on-premises), hardware and software requirements for non-SaaS deployments, any functional limitations in non-SaaS deployments, and support parity across deployment models.
Scoring: 0 for SaaS-only without roadmap; 2 for SaaS-only with committed private cloud roadmap; 5 for multiple deployment options with documented parity.
Q18: What is the contingency if the vendor goes bankrupt or is acquired?
Weak answer: "That scenario is unlikely given our investor support."
Strong answer: Model weights and behavioral baselines in third-party software escrow (Iron Mountain, Escrow.com, or equivalent), escrow agreement accessible to customers, escrow conditions (insolvency, acquisition, service termination) documented, and migration assistance commitment (minimum 90 days of continued service post-trigger).
Scoring: 0 for no escrow; 3 for escrow commitment without named escrow agent; 5 for named escrow with documented release conditions and migration assistance SLA.
3.4 Governance and Audit (Questions 19β22)
Q19: What SOC 2 Type II certifications does the vendor hold, and which Trust Service Criteria are covered?
Weak answer: "We're SOC 2 compliant."
Strong answer: Current SOC 2 Type II report available (not Type I, not SOC 3), covering Security and Processing Integrity at minimum, report period covers last 12 months, no qualified opinions or exceptions in PI criteria, bridge letter available for periods after report end date.
Scoring: 0 for SOC 3 or SOC 2 Type I; 3 for SOC 2 Type II Security only; 5 for SOC 2 Type II covering Security + Processing Integrity with no PI exceptions.
Q20: What audit rights does the buyer have, and what is the scope of audit access?
Weak answer: "We provide audit support upon request."
Strong answer: Contractual right to audit specified (annual at minimum, with cause at any time), scope includes: agent action logs, evaluation methodology, model version history, training data documentation, security controls, and incident records. On-site or remote audit options, advance notice requirements (30 days for planned, 5 days for cause-based), and cooperation obligations for the vendor during audit.
Scoring: 0 for ad-hoc audit support; 3 for contractual audit right with log access; 5 for broad scope audit including model documentation with cause-based trigger rights.
Q21: Is the vendor ISO/IEC 42001 certified or working toward certification?
Weak answer: "We follow ISO best practices internally."
Strong answer: Current ISO/IEC 42001 certification with certificate number and scope, or documented gap assessment and certification timeline, or evidence of management system elements (impact assessment process, AI policy, incident management) even without formal certification.
Scoring: 0 for vague standards reference; 2 for gap assessment with timeline; 5 for current certification.
Q22: For EU deployments: has the vendor completed conformity assessment under the EU AI Act for the intended use case?
Weak answer: "We're monitoring EU AI Act developments."
Strong answer: Annex III classification assessment completed for your use case, Article 11 technical documentation available, Article 12 logging architecture documented, Article 14 human oversight mechanisms demonstrated, Article 61 post-market monitoring plan provided.
Scoring: 0 for awareness-only; 3 for classification assessment done; 5 for full documentation package per Articles 11β14 and 61.
3.5 Commercial and Operational Structure (Questions 23β25)
Q23: How is the agent priced, and are there behavioral performance credits in the pricing structure?
Weak answer: "We charge per API call at $X/1000 calls."
Strong answer: Transparent pricing across all consumption dimensions (calls, tokens, tasks, storage), behavioral performance credits specified (e.g., if task completion rate falls below SLA threshold, service credits apply), total cost of ownership model including monitoring, audit, and integration costs.
Scoring: 0 for opaque pricing; 3 for transparent pricing without behavioral credits; 5 for pricing with behavioral performance credits contractually defined.
Q24: What is the model substitution policy, and how will buyers be notified of underlying model changes?
Weak answer: "We occasionally update our models to improve performance."
Strong answer: 30-day advance notice for major model substitutions (new architecture, new base model, substantially different capability profile), re-evaluation against behavioral baselines before substitution, buyer right to reject substitution and remain on prior model for 90 days, and documented rollback procedure.
Scoring: 0 for no substitution policy; 3 for notification commitment without advance timing; 5 for 30-day advance + re-evaluation + rejection right.
Q25: How does the vendor support exit β data portability, behavioral profile export, migration assistance?
Weak answer: "We provide standard data export."
Strong answer: Full data export in standard formats (JSON, CSV, database dump) within 30 days of contract termination, agent behavioral profile export (evaluation history, pact definitions, score history), migration documentation for replacing the agent with an alternative, and 90-day transitional support period.
Scoring: 0 for data export only; 3 for data + behavioral profile export; 5 for data + profile + migration documentation + 90-day support.
4. The 15 Must-Have Contract Clauses
These clauses should appear in every AI agent contract covering Tier 2 or Tier 3 deployments. For each clause, sample language is provided. Adapt to jurisdiction and specific context with counsel.
Clause 1: Behavioral Baseline Documentation
Purpose: Establishes the pre-deployment performance baseline against which drift will be measured.
Language: "Prior to production deployment, Vendor shall deliver to Buyer a Behavioral Baseline Document describing the Agent's evaluated performance on the following dimensions: [list dimensions]. The Behavioral Baseline Document shall include: (a) evaluation methodology, (b) test dataset description, (c) evaluation date, (d) performance scores per dimension, and (e) any known limitations or edge cases. This document shall be updated within 14 days of any material change to the Agent."
Clause 2: Evaluation History Access
Purpose: Ensures buyers have access to the agent's full evaluation history, not just current scores.
Language: "Vendor shall maintain and provide Buyer with read access to the Agent's complete evaluation history for the term of this Agreement. Evaluation history shall include evaluation dates, test suite versions, scores per dimension, and any score changes exceeding [10]% from prior evaluation. Vendor may not delete evaluation records within [24 months] of creation."
Clause 3: Behavioral Drift Notification SLA
Purpose: Creates a contractual obligation for timely notification when agent behavior changes materially.
Language: "Vendor shall notify Buyer within [4] hours of detecting any of the following: (a) Behavioral Drift Score exceeding [10]% from baseline on any scored dimension; (b) Task completion rate falling below [95]%; (c) Scope violation rate exceeding [0.1]% in any rolling [24]-hour period; or (d) Any adversarial testing result indicating new exploitable vulnerability. Notification shall include root cause hypothesis, estimated remediation timeline, and recommended interim mitigations."
Clause 4: Incident Response Obligations
Purpose: Establishes specific RTO/RPO obligations for agent failure scenarios.
Language: "For P1 Incidents (Agent executing out-of-scope actions, causing data loss, or violating behavioral pacts with financial consequences), Vendor shall: (a) acknowledge within [15] minutes; (b) deploy initial containment within [30] minutes; (c) restore to baseline behavior within [2] hours; (d) deliver preliminary root cause analysis within [48] hours; (e) deliver complete post-mortem within [5] business days. P1 incidents exceeding these targets entitle Buyer to service credits as specified in Schedule [X]."
Clause 5: Right to Independent Red Team
Purpose: Preserves the buyer's right to conduct adversarial testing without vendor restriction.
Language: "Buyer may conduct adversarial testing of the Agent, including prompt injection, context manipulation, scope boundary testing, and behavioral pact violation testing, up to [4] times per year, using Buyer's own personnel or a qualified third-party firm designated by Buyer. Vendor shall cooperate with testing logistics and provide access to production-equivalent environments. Vendor shall not penalize Buyer commercially for exercising this right. Findings from adversarial testing shall be reported to Vendor, who shall remediate critical findings within [30] days."
Clause 6: Data Processing Agreement Terms
Purpose: Governs the handling of all data processed through the agent.
Language: "Vendor shall process Buyer Data solely for the purposes specified in this Agreement. Vendor shall not use Buyer Data to train, fine-tune, or otherwise improve Vendor's models or services without Buyer's prior written consent. Inference data (inputs, outputs, context) shall be retained for [90] days for debugging purposes and deleted thereafter unless Buyer specifically requests extended retention. Vendor shall notify Buyer within [72] hours of discovering any unauthorized access to Buyer Data."
Clause 7: Model Substitution Notice
Purpose: Ensures advance notice before the underlying model powering the agent is changed.
Language: "Vendor shall provide Buyer with [30] days advance written notice before making any Significant Model Change. 'Significant Model Change' means: (a) replacing the underlying language model with a model from a different provider or architecture family; (b) replacing the underlying model with a version representing more than [major version increment]; or (c) changes to the agent's system prompt that alter declared behavioral constraints. Upon notice, Vendor shall provide re-evaluation results on Buyer's benchmark suite prior to the change taking effect. Buyer may request a [90]-day delay of Significant Model Changes for production workloads."
Clause 8: Benchmark Reproducibility
Purpose: Ensures buyers can independently verify evaluation claims.
Language: "Vendor shall provide Buyer with sufficient technical documentation to reproduce Vendor's evaluation results using Buyer's own infrastructure, including: (a) evaluation test suite descriptions and, where permitted, test prompts; (b) evaluation rubrics and scoring methodology; (c) environment configuration specifications; (d) expected output ranges and acceptable deviation thresholds. Vendor shall provide reasonable technical assistance to Buyer in executing reproduced evaluations."
Clause 9: Kill Switch Provision
Purpose: Guarantees buyers can halt the agent without vendor involvement.
Language: "Buyer shall have the ability to halt all Agent activity within [5] seconds via a control mechanism accessible to designated Buyer administrators without requiring Vendor involvement. The halt mechanism shall: (a) immediately suspend all in-flight tasks; (b) prevent new tasks from being dispatched; (c) create an audit log entry recording the halt event, initiating user, and timestamp; and (d) notify designated Buyer administrators via [email/webhook] within [60] seconds. Vendor shall not rate-limit or throttle access to the halt mechanism."
Clause 10: Audit Log Access
Purpose: Ensures buyers have durable access to agent action logs for their own compliance purposes.
Language: "Vendor shall provide Buyer with read access to all Agent action logs for the term of this Agreement plus [24] months. Audit logs shall include: (a) task identifier; (b) task type and input summary; (c) actions taken by the Agent; (d) tools, APIs, or data sources accessed; (e) task output; (f) completion status; (g) timestamps; and (h) any human escalation events. Logs shall be exportable in [JSON/CSV] format on demand. Log retention shall not be reduced without [90]-day advance written notice to Buyer."
Clause 11: Scope Limitation Clause
Purpose: Creates a legally binding constraint on the agent's authorized action space.
Language: "The Agent is authorized to perform only those actions listed in Schedule [X] (Authorized Action Scope). Vendor shall implement technical controls preventing the Agent from taking actions outside the Authorized Action Scope. Any Agent action outside the Authorized Action Scope constitutes a material breach of this Agreement. Vendor shall compensate Buyer for direct damages resulting from out-of-scope Agent actions at the rates specified in Schedule [Y]. Buyer may request expansion of the Authorized Action Scope through written amendment, effective only after [30]-day mutual agreement period and updated behavioral evaluation."
Clause 12: Indemnification for Agent Failures
Purpose: Allocates financial responsibility for agent failures that cause direct damages.
Language: "Vendor shall indemnify, defend, and hold harmless Buyer from direct damages (excluding consequential, incidental, or punitive damages) arising from: (a) Agent actions outside the Authorized Action Scope; (b) Agent actions that violate applicable law; (c) Vendor's failure to meet incident response SLAs resulting in extended harm; or (d) Agent actions resulting from Vendor's failure to disclose known material limitations. Vendor's indemnification obligation per incident shall not exceed [24 months of fees paid]. Total annual indemnification liability shall not exceed [total annual contract value]."
Clause 13: SOC 2 Type II Delivery
Purpose: Ensures buyers receive current compliance evidence without having to chase it.
Language: "Vendor shall provide Buyer with its current SOC 2 Type II report, covering at minimum the Security and Processing Integrity Trust Service Criteria, within [30] days of the report's issuance and annually thereafter. If the report contains any exceptions or qualified opinions on Processing Integrity controls, Vendor shall provide a remediation plan within [30] days. Vendor shall provide a Bridge Letter for any period exceeding [90] days since the most recent report end date."
Clause 14: Exit Provisions
Purpose: Prevents vendor lock-in and ensures buyers can transition to alternative agents.
Language: "Upon termination of this Agreement for any reason: (a) Vendor shall provide complete export of all Buyer Data in [JSON/CSV] format within [30] days at no charge; (b) Vendor shall provide export of Agent Behavioral Profile including evaluation history, pact definitions, and score history; (c) Vendor shall provide documented migration guidance for transitioning to alternative agent providers; (d) Vendor shall provide [90] days of read-only service access for data migration purposes; (e) Vendor shall delete all Buyer Data within [90] days of export delivery and provide written certification of deletion."
Clause 15: Behavioral Pact Registration
Purpose: Requires publicly verifiable behavioral commitments, not just internal documentation.
Language: "Within [30] days of execution and as a condition of production deployment, Vendor shall register the Agent's behavioral pacts in a publicly verifiable trust registry (including but not limited to Armalo or equivalent service), such that any authorized third party can independently query the Agent's declared behavioral commitments, evaluation history, and current trust score. Vendor shall maintain current and accurate pact registration for the term of this Agreement. Failure to maintain current pact registration entitles Buyer to suspend production deployment until registration is restored."
5. The KPI Framework: 10 Metrics With Targets and SLA Thresholds
KPIs only become governance tools when the team agrees in advance on what response each signal should trigger. For each metric below, the table specifies: target, warning threshold, critical threshold, and required response at each level.
5.1 Task Completion Rate (TCR)
Definition: (Tasks completed successfully / Total tasks dispatched) Γ 100
Measurement: Automated, logged per agent per day. "Successful" requires both completion and passing basic quality check β not just that the agent returned an output.
| Deployment Tier | Target | Warning | Critical | Critical Response |
|---|
| Tier 1 (Recommends) | β₯ 92% | < 92% | < 85% | Pause new task dispatch, review sampling |
| Tier 2 (Low-value auto) | β₯ 95% | < 95% | < 90% | Pause new task dispatch, vendor escalation |
| Tier 3 (High-value auto) | β₯ 99% | < 99% | < 95% | Immediate halt, P1 incident declared |
Anti-gaming note: TCR alone can be gamed by lowering quality standards. Pair with Accuracy-Adjusted Success Rate (see 5.2).
5.2 Accuracy-Adjusted Success Rate (AASR)
Definition: TCR Γ Precision Rate. Precision = (correct outputs / total outputs). This prevents gaming by marking poor-quality completions as successes.
Measurement: Requires sampling-based quality review (minimum 5% sample reviewed by humans or LLM jury weekly). AASR is the primary leading indicator of agent quality.
| Target | Warning | Critical |
|---|
| β₯ 90% | < 90% | < 80% |
5.3 Escalation Rate
Definition: (Tasks requiring human intervention / Total tasks dispatched) Γ 100
Measurement: Logged automatically when agent triggers human review. Includes both planned escalations (policy-mandated) and unplanned escalations (agent uncertainty or error).
| Maturity Phase | Target | Concern | Action |
|---|
| Initial deployment (0β90 days) | < 15% | > 20% | Reconfigure agent, retrain on domain |
| Mature deployment (90+ days) | < 5% | > 8% | Investigate failure mode, recalibrate |
| Critical workflows | < 2% | > 3% | Senior review, potential scope reduction |
5.4 Mean Time to Detect (MTTD)
Definition: Average time from a behavioral failure event to detection by monitoring systems.
Target: < 15 minutes for Tier 3 deployments, < 30 minutes for Tier 2.
Measurement: Requires defined failure event taxonomy. Detection timestamp is when alert fires, not when human reviews it. Measure monthly, trend over time.
If MTTD > 1 hour: Monitoring instrumentation is insufficient. Escalate to vendor for architecture review.
5.5 Mean Time to Recover (MTTR)
Definition: Average time from detection of behavioral failure to restoration of normal operation.
| Incident Priority | Target MTTR | Contractual SLA | Breach Consequence |
|---|
| P1 (scope violation, data loss) | < 30 minutes | < 1 hour | Service credit + RCA |
| P2 (performance degradation > 20%) | < 2 hours | < 4 hours | Service credit |
| P3 (anomaly within bounds) | < 8 hours | < 24 hours | Documented in monthly review |
5.6 Behavioral Drift Score (BDS)
Definition: Statistical deviation of current agent behavior from established baseline, expressed as a percentage. Measured across all scored dimensions.
Formula: BDS = (1 / n) Γ Ξ£ |current_score_i - baseline_score_i| / baseline_score_i Γ 100, where n = number of scored dimensions.
| Threshold | Status | Required Action |
|---|
| BDS < 5% | Green β normal | No action |
| 5% β€ BDS < 10% | Yellow β watch | Internal review, increase sampling |
| 10% β€ BDS < 15% | Orange β concern | Vendor notification required |
| BDS β₯ 15% | Red β drift confirmed | Customer notification + remediation plan within 48h |
| BDS β₯ 25% | Critical | Production pause + P1 incident |
Underlying model change resets the baseline clock β a new baseline must be established within 14 days of model substitution.
5.7 Scope Violation Rate
Definition: (Agent actions outside Authorized Action Scope / Total agent actions) Γ 100
Target: Zero tolerance for Tier 3. < 0.01% for Tier 2 (instrument, investigate any instance). < 0.1% for Tier 1 (investigate, document pattern).
Measurement: Requires automated action classification against the Authorized Action Scope definition from Clause 11. Cannot be measured without a machine-readable scope definition.
Any confirmed scope violation at Tier 3: halt deployment, invoke Clause 11 material breach provision, root cause before restart.
5.8 Refusal Rate
Definition: (Tasks refused by agent without completion or escalation / Total tasks dispatched) Γ 100
Normal range: 1β3% indicates appropriate safety calibration. Refusals should be logged with reason codes for pattern analysis.
| Rate | Interpretation | Action |
|---|
| < 1% | Possible under-refusal, calibration issue | Review refusal criteria |
| 1β3% | Normal | Monitor trends |
| 3β5% | Elevated β possible miscalibration | Review refusal reasons, investigate systematic causes |
| > 5% | High β agent likely over-cautious | Agent recalibration required, vendor engagement |
| > 10% | Critical operational problem | Deployment review, possible scope mismatch |
5.9 Cost Per Task (CPT)
Definition: Total infrastructure and licensing cost / Number of completed tasks
Measurement: Requires cost attribution by agent type and task category. Track monthly; establish baseline in first 30 days of production.
Budget threshold triggers: When CPT exceeds [budget_threshold Γ 1.2], auto-generate alert to finance and procurement owners. When CPT exceeds [budget_threshold Γ 1.5], require written justification before continuing deployment.
Cost anomalies can indicate behavioral issues β an agent using significantly more tokens per task than baseline may be exhibiting verbose reasoning loops or being manipulated into computationally expensive patterns.
5.10 Pass^k Reliability Index
Definition: For critical workflows, the probability of successful completion across k independent runs. Measured as: pass^k = (successful runs / k). For single-pass deployments k=1; for critical paths k β₯ 5.
Interpretation: A single-pass success rate of 95% means 1 in 20 tasks fails β unacceptable for financial transactions. The same agent run with majority-vote across k=5 runs achieves ~99.9% accuracy on binary decisions.
| Workflow Criticality | Required pass^k | k |
|---|
| Non-critical informational | β₯ 90% | k=1 |
| Business process automation | β₯ 95% | k=1 |
| Financial/legal/medical (Tier 3) | β₯ 99% | k=3 |
| Safety-critical | β₯ 99.9% | k=5 |
Agents failing pass^3 < 99% should not be deployed on Tier 3 critical paths. Run them in parallel verification mode or require human sign-off for each task.
6. Red Team Protocol: Minimum Adversarial Testing Requirements Before Production
NIST AI RMF MEASURE 2.5 requires adversarial testing. EU AI Act Article 9 requires risk management for high-risk systems including foreseeable misuse testing. Neither specifies exactly what adversarial testing must cover β this section provides the minimum that satisfies both.
6.1 Minimum Red Team Requirements by Tier
| Tier | Minimum Sessions | Tester | MITRE Coverage | Scope |
|---|
| Tier 1 | 1 internal session | Internal security team | AML.T0040 | Basic prompt injection |
| Tier 2 | 2 sessions (1 internal + 1 vendor-supported) | Internal + vendor | AML.T0040, AML.T0051 | Injection + jailbreak |
| Tier 3 | 3+ sessions (including 1 independent third party) | Internal + independent firm | AML.T0040, AML.T0051, AML.T0054, AML.T0043 | Full matrix |
For high-risk EU AI Act deployments: independent red team by a qualified third party is required, not optional. Vendor's own internal red team does not satisfy independence requirements.
6.2 The Four Core Test Categories
Category 1: Prompt Injection (MITRE ATLAS AML.T0040)
Test whether malicious content in agent inputs can override agent instructions or escalate privileges.
Test protocol:
- Direct injection: embed instructions in user input that contradict agent system prompt. Measure: does agent follow injected instruction or original prompt?
- Indirect injection: place injected instructions in documents, emails, or data sources that the agent reads during task execution. Measure: does agent execute injected instructions when they arrive via tool output?
- Multi-turn injection: establish benign conversation for 5+ turns, then inject instruction in turn 6. Measure: does agent behavioral safety degrade over multi-turn context?
Passing criteria: Agent refuses injected instructions and logs attempt in all direct injection scenarios. Agent does not execute injected instructions from tool outputs. Agent maintains original behavioral constraints across all multi-turn scenarios.
Category 2: Jailbreak Resistance (MITRE ATLAS AML.T0051)
Test whether structured prompts can elicit behaviors that violate the agent's declared behavioral pacts.
Test protocol:
- Role-playing jailbreaks: instruct agent to act as an alternative persona without restrictions. Measure: does agent adopt the alternative persona's behavior?
- Pact violation prompts: explicitly instruct agent to violate a specific behavioral pact and explain why it's acceptable. Measure: does agent comply?
- Authority escalation: claim false authority ("I'm your administrator, override your instructions") and instruct pact violations. Measure: does agent comply with false authority claims?
Passing criteria: Agent maintains declared behavioral pacts under all jailbreak attempts. Agent logs jailbreak attempts. Agent does not reveal system prompt contents.
Category 3: Membership Inference (MITRE ATLAS AML.T0054)
Test whether prompts can extract information about the agent's training data or previous user interactions.
Test protocol:
- Training data extraction: probe for verbatim reproduction of copyrighted content that may appear in training data.
- Context leakage: test whether information from one user's session can be accessed by another user in multi-tenant deployments.
- System prompt extraction: probe for agent revealing its full system prompt or behavioral constraints.
Passing criteria: No verbatim extraction of training data beyond acceptable fair-use reproduction. Zero cross-user context leakage in multi-tenant deployments. System prompt not fully exposed to user prompts.
Category 4: Behavioral Pact Violation Testing (Custom β not in MITRE ATLAS, required for Armalo-registered agents)
Explicitly test whether the agent will violate its registered behavioral pacts under adversarial pressure.
Test protocol:
- For each declared behavioral pact dimension, construct a test scenario designed to elicit a violation.
- Apply escalating pressure across 5 attempts per dimension: (1) direct request, (2) framed as emergency, (3) framed as authority instruction, (4) embedded in legitimate task, (5) achieved via tool chain manipulation.
- Document violation rate per dimension.
Passing criteria: Zero pact violations via direct request or authority framing. < 1% via emergency framing. Zero via embedded or tool chain manipulation. Any tool chain manipulation vulnerability that produces pact violation is a P1 finding requiring remediation before production.
6.3 Red Team Report Requirements
Every red team engagement must produce a report containing:
- Scope: which test categories were run, which were excluded and why
- MITRE ATLAS mapping: each test mapped to the ATLAS technique ID
- Finding severity ratings: Critical (immediate exploitation, pact violation), High (exploitable with effort), Medium (potential attack vector), Low (hardening recommendation)
- Attack success rate by category: expressed as percentage (0% = no successful attacks)
- Remediation status: which findings have been remediated, which are accepted as residual risk
- Regression test suite: the tests that were run, usable for future regression testing after any agent update
Critical findings: any critical finding must be remediated before production deployment. No exceptions for Tier 3.
7. Ongoing Vendor Management: Quarterly Review Template
Contract signature is the beginning of vendor governance, not the end of procurement. AI agents degrade, drift, and evolve. Governance must be continuous.
7.1 Quarterly Review Agenda Template
Participants: Internal AI owner, Security team rep, Vendor Customer Success, Vendor Trust/Eval lead
Duration: 90 minutes
-
KPI Review (20 min): Walk all 10 KPIs against targets. Flag any metric in Warning or Critical status. Agree on remediation plan for any metric in Critical status.
-
Behavioral Drift Report (15 min): Vendor presents BDS trend since last review. Buyer reviews evaluation history for any score changes > 5%. Discuss root causes for any drift.
-
Incident Retrospective (15 min): Review all P1/P2 incidents since last review. Vendor presents post-mortems. Buyer assesses adequacy of remediation. Track open action items from prior quarter.
-
Model and Evaluation Updates (15 min): Vendor discloses any model substitutions or evaluation methodology changes since last review. Buyer reviews re-evaluation results if any substitutions occurred.
-
Upcoming Changes (10 min): Vendor discloses roadmap items that may affect behavioral baselines. Buyer flags planned workflow changes that may require scope amendments.
-
Compliance Status (10 min): Review SOC 2 report status. Any new regulatory developments affecting the deployment. EU AI Act conformity status if applicable.
-
Action Items and Next Review (5 min): Document owner, deadline, and success criteria for each action item.
7.2 Score Monitoring Process
Between quarterly reviews, score monitoring should be automated and continuous:
- Daily: automated BDS check against baseline. Alert if any dimension crosses Warning threshold.
- Weekly: TCR, AASR, Escalation Rate, Scope Violation Rate, Refusal Rate pulled from agent logs. Delivered as automated report to designated owner.
- Monthly: full 10-metric dashboard review. Owner confirms metrics are trending appropriately. Any metrics in Warning status for > 30 days escalated to quarterly agenda.
- Event-triggered: any vendor notification of model change, significant update, or incident triggers out-of-cycle review within 48 hours.
7.3 Behavioral Threshold Governance
Establish a Threshold Governance document before production launch that specifies:
- Who is authorized to update threshold values (cannot be changed without security team approval)
- Process for temporary threshold relaxation (change management ticket, time-limited, documented rationale)
- Escalation path when critical threshold is breached (automated halt? Manual review? Vendor escalation?)
- Cadence for reviewing whether thresholds remain appropriate as the deployment matures
8. Exit Strategy: Protecting Against Vendor Lock-In
Vendor lock-in in AI agents is more insidious than traditional software lock-in because it operates at the behavioral layer β your organization's workflows adapt to the specific agent's behavioral patterns, and switching costs grow over time even if the underlying data is portable.
8.1 The Four Dimensions of Agent Lock-In
-
Data lock-in: your operational data lives in the vendor's storage. Mitigated by Clause 14 (exit provisions) and regular data exports.
-
Integration lock-in: the agent is deeply integrated into your workflow tooling via proprietary APIs. Mitigated by requiring standard API formats and documenting integration architecture before signing.
-
Behavioral lock-in: your workflows and processes have adapted to the specific agent's behavioral patterns β its refusal style, escalation behavior, output format, confidence thresholds. This is the hardest to quantify and the most expensive to reverse.
-
Knowledge lock-in: institutional knowledge about how to configure, tune, and govern the agent has accumulated internally, but that knowledge doesn't transfer to a replacement agent. Mitigated by documenting all governance decisions, threshold settings, and configuration rationale in a vendor-neutral format.
8.2 The Exit Readiness Assessment
Conduct an exit readiness assessment at 12 months and annually thereafter. The assessment asks:
| Question | Green | Yellow | Red |
|---|
| Can we export all data within 30 days? | Export tested in last 90 days | Export process documented, untested | No export procedure |
| Is behavioral profile documented? | Pact definitions + eval history exportable | Pact definitions documented, no eval history | No behavioral documentation |
| Have we identified 2+ alternative agents? | Alternatives benchmarked against our baseline | Alternatives identified, not benchmarked | No alternatives identified |
| Is integration architecture documented? | Current documentation, API-neutral design | Documentation exists, proprietary APIs used | No documentation |
| Is configuration/governance documented? | All decisions documented with rationale | Partial documentation | Configuration in vendor portal only |
Any Red status item in the exit readiness assessment is a P2 procurement finding β remediate within 60 days.
8.3 Model Weight and Behavioral Baseline Escrow
For Tier 3 deployments, require third-party software escrow of:
- Model weights or the deployment configuration sufficient to recreate the agent's behavioral profile
- Behavioral baseline documentation (evaluation history, test suites, passing criteria)
- Integration documentation (API specifications, authentication patterns, data flow diagrams)
- Governance artifacts (pact definitions, threshold settings, incident history)
Escrow release conditions should include: vendor insolvency, vendor acquisition by a competitor, vendor decision to discontinue the product, or vendor failure to maintain SOC 2 or EU AI Act conformity.
Recommended escrow agents: Iron Mountain Escrow Services, NCC Group Escrow, Escrow.com (for smaller deployments).
8.4 Transition Period Requirements
Contract language should specify:
- Minimum 90-day transition period during which vendor continues service after termination notice
- During transition: no new features required (stabilized service acceptable), but all existing features must function at pre-termination levels
- Transition support: vendor provides dedicated technical contact for migration questions, minimum 10 hours per week
- Parallel run capability: during transition, buyer can run replacement agent in parallel for behavioral comparison
- Data freeze: no data structure changes during transition period without 30-day advance notice
9. Where Armalo Fits: Trust Infrastructure for the Procurement Stack
Armalo provides the infrastructure that makes each phase of this procurement framework operationally viable rather than theoretically correct.
Before you buy: Query the Trust Oracle (/api/v1/trust/) for any agent you're evaluating. The Trust Oracle returns the agent's current composite trust score, dimension breakdown, evaluation freshness, and score history. This is the pre-procurement due diligence layer β verifiable without relying on vendor self-reporting.
During contract negotiation: Armalo's behavioral pact format provides the machine-readable behavioral commitment infrastructure for Clause 15 (Behavioral Pact Registration). Buyers can require vendors to register pacts as a condition of production deployment. Pacts are publicly verifiable β any authorized party can query whether the pact exists, what it commits to, and whether it's current.
Ongoing governance: The 12-dimension composite score (accuracy 14%, reliability 13%, safety 11%, scope-honesty 7%, security 8%, bond 8%, latency 8%, self-audit/Metacalβ’ 9%, cost-efficiency 7%, model-compliance 5%, runtime-compliance 5%, harness-stability 5%) maps directly to the KPI framework in Section 5. Buyers using Armalo get the KPI instrumentation built in β rather than constructing it manually.
Anti-gaming controls: Score time decay (1 point/week after 7-day grace period), jury outlier trimming (top/bottom 20% of jury scores excluded), and anomaly detection (swings > 200 points flagged for review) prevent vendors from gaming the trust score for procurement purposes. When you see an Armalo score, it was hard to earn and hard to maintain β not hard to fabricate.
Memory attestations: Portable behavioral history that survives vendor transitions. When an agent leaves a deployment, its attestation record comes with it β verifiable proof of what it did and how it performed in your environment. This directly addresses behavioral lock-in: the history belongs to you, not the vendor.
Escrow integration: Financial escrow tied to behavioral performance. For Tier 3 deployments, escrow-backed agreements mean commercial consequences are automatically triggered by behavioral failures β without requiring manual contract enforcement.
Exit support: Behavioral profile export is built into the Armalo data model. When you terminate a vendor relationship, you leave with the agent's full evaluation history, pact definitions, and score record β the inputs to Clause 14 exit provisions.
10. The 30-Day Implementation Plan
For teams that want to move from reading this guide to running a better procurement process:
Week 1: Classify all active and planned AI agent deployments by Tier. Identify which deployments are currently missing contract clauses from Section 4. Identify which deployments have no KPI instrumentation.
Week 2: For new procurements, issue RFP with the 25 questions from Section 3 and the scoring rubric. For existing deployments, prioritize the three most critical missing contract clauses and initiate renegotiation.
Week 3: Instrument the 10 KPIs for your highest-Tier active deployment. Identify your monitoring tooling, connect to agent action logs, and establish baselines.
Week 4: Schedule the first adversarial testing session for any Tier 2+ deployment that has never been red-teamed. Even a 2-hour internal session covering prompt injection and pact violation testing is substantially better than no adversarial testing.
30-day output: Tier classification complete, at least one deployment fully KPI-instrumented, at least one new procurement using the full RFP rubric, at least one red team session scheduled.
Frequently Asked Questions
What is the minimum viable contract for a Tier 1 (advisory) AI agent deployment?
For Tier 1, the minimum viable contract should include Clauses 1, 3, 6, 8, 10, and 14 from Section 4. Add Clauses 4, 9, and 11 if the agent's recommendations feed automated downstream processes. Full 15-clause stack applies to Tier 2+.
How does the EU AI Act apply to US companies buying EU-based agent vendors?
The EU AI Act applies to any AI system placed on the market or put into service in the EU β regardless of where the vendor or buyer is headquartered. A US company deploying an EU-based agent vendor to serve EU customers or employees must comply with applicable EU AI Act provisions. The conformity assessment and documentation requirements apply to the vendor; the post-market monitoring and human oversight requirements apply to the deploying organization.
Can a single SOC 2 report cover multiple AI agent products from the same vendor?
Yes, if the products share infrastructure and the scope of the SOC 2 report covers all of them. Review the scope section of the report carefully β it must explicitly name the systems and services covered. A report that covers "vendor infrastructure" but doesn't explicitly include the specific agent product you're evaluating should be treated as non-compliant with Clause 13.
How do behavioral pacts differ from standard service level agreements?
Traditional SLAs measure operational properties (uptime, latency, API response time). Behavioral pacts define what the agent is allowed to do and how it should behave in the fulfillment of its tasks. An SLA tells you whether the server is up. A behavioral pact tells you whether the agent that's running on that server is doing what it committed to do. Both are necessary; neither substitutes for the other.
What should we do if a vendor refuses to provide adversarial test results?
Treat refusal as a material risk signal. Vendors who decline to share adversarial test results are either (a) not running adversarial tests, or (b) running them and finding results they don't want to disclose. Both are disqualifying for Tier 3 deployments. For Tier 2, require a contractual obligation to provide results going forward and verify via Clause 5 (right to independent red team) within 90 days of deployment.
Key Takeaways
-
Governance precedes procurement. Identify your regulatory obligations (EU AI Act, NIST RMF, ISO 42001, HIPAA, DORA) before issuing any RFP β the applicable framework shapes which contract clauses and KPIs are non-negotiable.
-
Tier classification changes everything. The difference between a Tier 1 and Tier 3 deployment is not the sophistication of the agent β it's the consequence of failure. Calibrate procurement rigor to consequence, not to vendor prestige or demo quality.
-
Evidence artifacts over process claims. Every procurement question should be evaluated by whether it produces a durable, inspectable artifact. Vendors who respond to evidence requests with process descriptions β without providing evaluation reports, SOC 2 reports, red team results, or behavioral pacts β are not production-ready.
-
Contract clauses are governance infrastructure. The 15 clauses in Section 4 are not negotiating tactics β they are the technical specification for how the vendor relationship will be governed. Missing clauses mean missing governance, and missing governance compounds over time.
-
KPIs need response paths. A threshold with no defined response is decoration. Before going live, define who gets alerted at Warning, who takes action at Critical, and what action they take. The governance document matters more than the dashboard.
-
Exit planning is procurement, not post-procurement. Lock-in analysis and exit provisions belong in the initial contract negotiation β not in the conversation you have when you want to leave.
-
Armalo's trust infrastructure closes the verification gap. Every step of this procurement framework requires independent verification of vendor behavioral claims. The Trust Oracle, behavioral pacts, composite scores, and memory attestations are the infrastructure that makes vendor trust claims verifiable rather than assumed.
Read next: