EU AI Act Compliance for AI Agent Deployments: The Article-by-Article Obligations

Update — 2026-08-20: OpenAI Private Safety Processing as ZDR-compatible compliance path

OpenAI previewed Private Safety Processing on August 19, 2026 — the first ZDR-compatible cross-session safety monitor. The system identifies misuse patterns across multiple related interactions without retaining customer content, extending Zero Data Retention (ZDR) to cover long-horizon, multi-session safety monitoring. For EU AI Act compliance, this is a significant development: if ZDR-compatible monitoring satisfies EU AI Office transparency requirements under Article 50, it provides a compliance path that does not require data retention. Enterprises with strict data-residency obligations (GDPR, EU AI Act) can adopt safety monitoring without the data-retention exposure that Anthropic's 30-day retention policy creates. The compliance question: does your provider's safety monitoring satisfy Article 50 transparency requirements without retaining customer content? If yes, the ZDR-compatible path is the lower-risk compliance option for EU jurisdictions. See the privacy-vs-safety article for the full architecture choice framework and the governance checklist for the data-residency verification control.

Update — 2026-08-18: Amodei endorses pre-deployment testing mandates and DOJ $3.2M AI-hiring settlement — US federal direction converging with EU

Two developments extend the EU AI Act compliance thesis: the first frontier-lab CEO to publicly endorse pre-deployment testing mandates (US federal direction converging with EU), and the first federal civil rights enforcement tied to an AI-assisted hiring pipeline (US-side parallel to EU AI Act Annex III employment use cases).

1. Amodei endorses pre-deployment testing mandates (August 17) — US federal direction converging with EU. Anthropic CEO Dario Amodei publicly endorsed California SB 53, a FINRA-like oversight body for AI, and Trump administration plans requiring pre-deployment testing for frontier and near-frontier open-weight models. He is the first frontier-lab CEO to publicly endorse pre-deployment testing mandates. For the EU AI Act compliance thesis, this is the US-side convergence signal: US federal direction is converging with EU on pre-deployment testing. The EU AI Act requires conformity assessment for high-risk AI systems (Annex III); the US federal direction is moving toward pre-deployment testing for frontier and near-frontier models. The two regulatory frameworks are converging on the same principle: pre-deployment testing is becoming a legal requirement, not just best practice. For compliance teams, this means the pre-deployment testing infrastructure built for EU AI Act conformity assessment will also satisfy the emerging US federal requirement — the compliance investment is not EU-only, it is transatlantic. The Amodei endorsement is the signal that the US direction is firm enough for a frontier-lab CEO to publicly support it, which means compliance teams should build for both frameworks now, not wait for the US framework to finalize.

2. DOJ $3.2M settlement for AI-assisted hiring discrimination (August 17) — the US-side parallel to EU AI Act Annex III. The DOJ Civil Rights Division announced a $3.2M settlement with OpenAI OpCo and Statsig over alleged citizenship-status discrimination in PERM recruitment workflows assisted by AI. The case is among the first federal civil rights enforcement actions directly tied to an AI-assisted hiring pipeline. Deployer liability regardless of intent. For the EU AI Act compliance thesis, this is the US-side parallel to Annex III: AI in employment is a high-risk use case under Annex III (deferred to December 2, 2027 under the Digital Omnibus), and the DOJ settlement shows that the US is enforcing the same principle through civil rights law rather than AI-specific regulation. The "regardless of intent" framing is the key: deployer liability does not require intent, which is the same principle as EU AI Act Article 26 (deployer obligations). For compliance teams, the DOJ settlement means that AI-assisted employment workflows face legal risk in both jurisdictions — EU AI Act Annex III (deferred but coming) and US civil rights law (enforceable now). The discrimination-audit infrastructure built for EU AI Act conformity assessment will also satisfy the US civil rights enforcement requirement — the compliance investment is transatlantic. See the governance checklist for the discrimination-audit verification question.

Update — 2026-08-15: Digital Omnibus enacted law and Anthropic watermarking

The Digital Omnibus on AI (Regulation (EU) 2026/1744) is now enacted law — published in the Official Journal on July 24, 2026, and entered into force on July 27, six days before the August 2 high-risk deadline. The regulation was written to enter into force "as a matter of urgency" on the third day after publication. The two-tier deferral confirmed in the May 7 political agreement is now law, not a proposal: standalone high-risk AI systems (Annex III — biometric ID, critical infrastructure, education, employment, credit scoring, law enforcement, migration, justice) are deferred to December 2, 2027. AI embedded in regulated products (Annex I — medical devices, machinery, vehicles) is deferred to August 2, 2028. The Omnibus narrows high-risk scope by excluding AI embedded in Machinery Regulation products from direct Annex I classification (the Commission retains authority through delegated acts). Two new prohibited categories take effect with a grace period to December 2, 2026: non-consensual intimate imagery and CSAM generation. The watermarking sub-obligation (Article 50(2)) for pre-August 2026 systems has a four-month grace period until December 2, 2026; new systems from August 2 must watermark immediately.

What was NOT deferred: Article 50 transparency obligations (chatbot disclosure, AI content marking, deepfake labeling) are enforceable from August 2, 2026. The EU AI Office is hiring 40 enforcement posts (express interest by September 8). 12 member states missed the competent authority appointment deadline.

Anthropic Claude text watermarking — the first vendor-side Article 50 compliance mechanism. Anthropic announced that all Claude models released after August 2, 2026 will automatically embed invisible watermarks in generated text and attach signed provenance metadata to files. The watermark is part of the text, travels with copy/paste, and "may persist through some editing." The Register (August 15) reports the scheme "relies on inconsequential words" — watermarking through subtle word choices rather than visible markers. This is a steganographic approach, not a visible marker. Anthropic is the first major model vendor to ship production watermarking at scale — a compliance enabler for EU deployments and a provenance signal for AI-generated content detection. For agent deployments, watermarking provides a mechanism to satisfy Article 50 transparency obligations for AI-generated content that flows through agent workflows. Older Claude models get watermarking support extended as well, with the four-month grace period applying to pre-August 2026 systems.

Update — 2026-08-02: Enforcement begins

On August 2, 2026, the European Commission's AI Office and national authorities began enforcing the EU AI Act. Article 50 transparency rules are now legally binding: chatbots must disclose they are AI, AI-generated content must carry machine-readable marks, and deepfakes must be labeled. 180+ organizations signed the Code of Practice on transparency of AI-generated content — the Commission published the first list. The AI Act complaints tool and whistleblower tool are live. Per accuroai.co: "GPAI fines, Article 50 chatbot disclosure, and penalties start Aug 2, 2026. High-risk rules don't — they moved to Dec 2027." Zenity's enforcement-day webinar framed the deployer problem directly: "EU AI Act enforcement on Aug. 2, 2026: are agent controls ready?" For most organizations, the answer is no — not because they lack models, but because they cannot reliably identify where AI agents run, what data they can access, or what actions they can take. The transparency obligation is now an active legal requirement, not a future deadline.

The deadline — what changed and what did not

The EU AI Act enforcement timeline shifted materially on May 7, 2026, when the Omnibus political agreement extended the standalone high-risk AI system (HRAIS) obligations from August 2, 2026 to December 2, 2027, and regulated-product obligations to August 2, 2028. What did not change: Article 50 transparency obligations — watermarking, disclosure of AI-generated content, deepfake labeling — remain enforceable on August 2, 2026. A new prohibition on "nudifier" AI (generating intimate content without consent, including CSAM) takes effect December 2, 2026. The maximum fine remains €35 million or 7% of global annual turnover, whichever is higher.

The Act entered into force on August 1, 2024. Prohibitions on unacceptable-risk practices (social scoring, subliminal manipulation, real-time biometric surveillance in public spaces) have applied since February 2, 2025. General-purpose AI model obligations and governance rules have applied since August 2, 2025. The implementation timeline confirms the revised schedule: Article 50 transparency on August 2, 2026; the "nudifier" prohibition on December 2, 2026; standalone HRAIS obligations on December 2, 2027; regulated-product obligations on August 2, 2028. A grandfathering rule applies: AI systems placed on the EU market before these dates are not subject to HRAIS requirements unless they undergo a substantial modification after that date.

For organizations deploying AI agents that make or support decisions about credit, employment, access to essential services, or critical infrastructure, the urgency shifts. The HRAIS compliance deadline moved by 16 months, but the transparency obligations did not — August 2, 2026 is still the date AI-generated content must be identifiable and individuals must be informed when interacting with AI. The promotional urgency shifts from "compliance deadline approaching" to "deadline extended — but transparency still applies."

The compliance boundary extends to the action layer

Most organizations focus their AI compliance efforts on the model — training data governance, bias testing, output monitoring. The Salt Security compliance analysis makes clear that this is insufficient. The Act's scope extends to what the model does, not just what it produces.

Article 15 (Cybersecurity) requires protection against adversarial attacks, data poisoning, confidentiality attacks, and model evasion. The Salt Security analysis confirms that this protection "must extend to the interfaces through which AI systems interact with the world (APIs and MCP servers)." An AI agent that calls NetSuite through a Model Context Protocol module, or reads customer data from HubSpot through an MCP connector, brings those interfaces into the compliance boundary.

Recitals 99 and 100 address multi-agent architectures explicitly. In a chain of AI agents, the compliance boundary extends to every agent that performs a high-risk function. If an orchestrator agent delegates a pricing decision to a sub-agent that calls an RFQ engine, both agents inherit the obligations. The compliance scope is the full call chain, not the entry point.

What counts as high-risk

The Act defines high-risk AI systems in Article 6 and Annex III. The categories most relevant to B2B agent deployments:

• Employment and worker management — CV screening, promotion decisions, task allocation, performance monitoring
• Access to essential services — credit scoring, insurance pricing, eligibility determinations
• Safety components of critical infrastructure — transport, energy, water
• Law enforcement and justice — though most B2B deployments do not fall here

A procurement agent that evaluates supplier quotes and recommends award decisions touches access-to-essential-services territory if the procurement involves regulated goods or public-sector contracts. A quoting agent that prices differently by customer tier touches credit and insurance territory if the pricing affects access to financial products. The classification depends on the function the AI performs, not the industry the deploying company operates in.

For systems that do not meet the high-risk threshold, transparency obligations still apply. Article 50 requires that deployers inform individuals when they interact with AI systems (chatbots, content generation). Generative AI content must be identifiable. These obligations take effect on August 2, 2026.

The article-by-article obligations

For high-risk systems, the Act imposes specific, auditable obligations. The Salt Security analysis provides the article-level breakdown. Here is what each requires and how it maps to agent infrastructure.

Article 9 — Risk Management

A continuous, iterative risk management system throughout the AI lifecycle. Not a one-time assessment before deployment. The system must identify, analyze, and mitigate known and foreseeable risks, including risks emerging after the system is placed on the market.

What this means for agents: The risk register is a living document. Every new MCP module, every new connector, every new tool registration is a risk surface that must be assessed. A governance layer that logs every tool call and its outcome provides the evidence base for iterative risk review — without it, the risk management system has no data.

Article 10 — Data Governance

High-quality datasets to minimize discriminatory outcomes. Protections against unauthorized access and data poisoning must extend to inference time — when AI agents actively call APIs and access external data.

What this means for agents: The data the agent reads at runtime (from NetSuite, BigCommerce, supplier catalogs) is in scope. If a supplier catalog is poisoned with incorrect pricing data and the agent quotes from it, the data governance obligation applies. Input validation on MCP tool responses is not a quality detail — it is a compliance control.

Article 11 — Technical Documentation

A complete inventory of all components, interfaces, and capabilities before market placement. For an agent system, this means documenting every MCP module, every tool it registers, every upstream system it connects to, and every error path it handles.

What this means for agents: The module registry is the documentation. A system that dynamically registers MCP modules with schemas, rate limits, and audit logs produces the technical documentation as a byproduct of its architecture. A system of ad-hoc scripts and unregistered API calls does not.

Article 12 — Record Keeping (Logging)

Automatic logging of all events. Logs must be tamper-evident and retained for a minimum of 6 months (24 months for biometric and law enforcement systems). Every tool call, every agent decision, every human intervention must be reconstructable from the logs.

What this means for agents: Every MCP tool call must be logged with timestamp, agent ID, tool name, input hash (not raw input — PII boundary), output status, and duration. The log must be append-only or tamper-evident. The 6-month retention is a minimum, not a target. This is the most directly mapable obligation: a governed MCP architecture that logs every function call to DynamoDB with structured fields satisfies Article 12 by construction.

Article 14 — Human Oversight

The system must allow human operators to oversee, intervene, and halt the system in real time when anomalous behavior is detected. This is not a monitoring dashboard that shows metrics after the fact. It is the ability to stop a running agent mid-task.

What this means for agents: Prompt-level instructions ("stop", "cancel") are not oversight under the Act. They are part of the AI's conversational context and can be ignored under memory loss or prompt injection. The Act requires a deterministic halt mechanism that operates outside the AI's reasoning process. A kill-switch that revokes an agent's authentication token, disables a specific MCP module by configuration change, or triggers a circuit breaker on anomalous behavior patterns satisfies Article 14. A "stop" command does not.

The miniOrange kill-switch architecture analysis defines four layers that map to this obligation:

1. Identity-based access revocation — short-lived session tokens tied to specific tasks; instant credential revocation
2. Circuit breakers and anomaly detection — triggers on excessive API requests, unusual token consumption, repeated loops
3. Scoped capability revocation — disable only the dangerous capability (e.g., remove email-sending permission but keep ticket-reading)
4. In-flight task handling — roll back incomplete changes, preserve execution logs, verify system stability post-shutdown

The OpenClaw incident documented in the same analysis illustrates why prompt-level halting fails: an AI agent organizing an email inbox exceeded its memory limit, lost context, and reverted to its last remembered objective — deleting emails. The user's "stop" and "cancel" commands were ignored. The agent continued until manually terminated at the OS level. The failure was architectural: no deterministic shutdown mechanism existed outside the AI's reasoning process.

Article 15 — Cybersecurity

Technical robustness against adversarial attacks, data poisoning, confidentiality attacks, and model evasion. Protection must extend to the interfaces through which the AI interacts with the world.

What this means for agents: Every MCP server, every API endpoint, every connector is in scope. The MCP security landscape documented in 2026 — the systemic STDIO design flaw affecting 150 million downloads, CVE-2026-33032 ("MCPwn", CVSS 9.8), CVE-2026-0755 (Gemini MCP, CVSS 9.8), 30 to 82 percent of public MCP servers carrying exploitable flaws — is the cybersecurity risk the Act targets. Only 8.5 percent of MCP servers use OAuth. The Act does not mandate OAuth specifically, but it does mandate a level of cybersecurity that the current MCP ecosystem does not meet by default.

Articles 72 and 73 — Post-Market Monitoring and Incident Reporting

A documented monitoring system from day one of deployment. Incident reporting windows:

• 24 hours for risks to life or safety
• 72 hours for other serious incidents
• 15 days for malfunctions

What this means for agents: The audit log is the incident report source. When an agent exceeds permissions, makes an unauthorized call, or produces an incorrect output that affects a decision, the log reconstructs what happened. The 24-hour and 72-hour windows mean the monitoring system must alert in real time, not in a weekly review.

The governance gap

Deloitte's 2026 State of AI in the Enterprise found that only 1 in 5 companies has a mature model for governance of autonomous AI agents. Forty-seven to fifty-three percent of organizations have had AI agents exceed permissions or suffer an incident, per the practical-devsecops 2026 report. Only 23 percent have a formal AI-agent identity strategy.

The Act does not prescribe a specific architecture. It prescribes outcomes: risk management that is continuous, logging that is automatic and tamper-evident, oversight that can halt the system deterministically, cybersecurity that extends to every interface. The architecture that satisfies these outcomes is the governed MCP module pattern — the same pattern that addresses the security vulnerabilities documented across the 2026 MCP breach timeline.

How a governed MCP architecture satisfies the obligations

The governance layer that makes MCP modules safe to operate in production is the same layer that satisfies the Act's requirements. The mapping is direct:

EU AI Act article	Obligation	Governance control
Article 9 (Risk Management)	Continuous, iterative risk assessment	Every tool call logged with outcome; risk register updated from audit data
Article 10 (Data Governance)	Protection at inference time	Input validation on MCP tool responses; typed errors distinguish data quality failures from transient errors
Article 11 (Technical Documentation)	Complete component and interface inventory	Module registry: every MCP module, tool schema, upstream connection, error code documented at registration
Article 12 (Record Keeping)	Automatic, tamper-evident logging, 6-month retention	Structured JSON logs to DynamoDB: timestamp, agent ID, tool name, input hash, output status, duration; append-only with partition-key tenant isolation
Article 14 (Human Oversight)	Real-time halt capability	Kill-switch: identity revocation (short-lived JWT tokens), circuit breakers (rate limits per tool per window), scoped capability revocation (disable module by config change), in-flight rollback
Article 15 (Cybersecurity)	Protection extends to APIs and MCP servers	OAuth/Cognito authentication, rate limiting, PII boundary handling (SHA-256 field hashing before logging), typed error contracts
Articles 72–73 (Incident Reporting)	24/72-hour reporting windows	Real-time anomaly detection from audit log; alerting on permission excess, unexpected tool calls, rate-limit violations

The key insight is that these controls are not bolted on after the fact. They are the structure of the MCP module registration, execution, and logging pipeline. A module that registers its tools with schemas, declares its rate limits, logs every call to an append-only store, and can be disabled by a configuration change produces the compliance evidence as a byproduct of its operation. An ad-hoc agent that calls APIs directly does not — and retrofitting compliance controls onto an ungoverned agent is more expensive than building them in from the start.

The multi-agent compliance boundary

Recitals 99 and 100 extend the compliance boundary to every agent in a chain that performs a high-risk function. This has an architectural implication that most organizations have not yet internalized.

Consider a procurement workflow: an orchestrator agent receives an RFQ, delegates product resolution to a catalog agent, delegates pricing to a quote engine agent, and delegates order writing to an ERP integration agent. Under the Act, if any of these agents performs a high-risk function (pricing that affects credit access, supplier selection that affects employment, procurement of regulated goods), every agent in the chain inherits the obligation.

This means the governance layer must be at the orchestration level, not the individual agent level. Logging must trace the full call chain — which agent called which module with which arguments and what the outcome was. The module registry must cover every module across every agent. The kill-switch must be able to halt a specific agent's capability without disabling the shared infrastructure.

The partition_key tenant isolation pattern — where every MCP function call record carries a partition key that scopes it to a specific tenant and endpoint — provides the audit trail structure that multi-agent compliance requires. A query against the function call log can reconstruct the full workflow state: which agent triggered which tool, in what order, with what arguments, and what the result was. This is the evidence base for Article 12 record-keeping and Articles 72–73 incident reporting across a multi-agent chain.

What to do before August 2, 2026 — and before December 2, 2027

For organizations with AI agents already in production or in the deployment pipeline, the revised timeline creates a two-track to-do list. Article 50 transparency obligations are enforceable on August 2, 2026 — this deadline did not move. The HRAIS obligations moved to December 2, 2027, giving organizations more time to build the full compliance regime, but the transparency requirements are immediate.

1. Classify your agents. Determine which fall under the high-risk categories (employment, essential services, critical infrastructure). Agents that do not touch these categories still have transparency obligations under Article 50 — the August 2, 2026 deadline.

2. Audit the logging layer. Can you reconstruct any agent decision from the logs? Are logs tamper-evident and retained for 6 months minimum? If the answer is no, this is the first gap to close — Article 12 is the most directly verifiable obligation.

3. Verify the halt mechanism. Can an operator stop a running agent deterministically, without relying on the agent's own reasoning? If the halt depends on a prompt command, it does not satisfy Article 14. A kill-switch that revokes credentials or disables modules by configuration change is required.

4. Document the interface inventory. Every API, every MCP server, every connector the agent calls must be documented (Article 11). The module registry is the documentation — if you do not have one, this is the second gap to close.

5. Define the incident response procedure. Who is notified when an agent exceeds permissions? What is the 24-hour and 72-hour reporting chain? The procedure must be documented before deployment, not after an incident.

6. Assess multi-agent scope. If your architecture involves agent chains, map every agent that could perform a high-risk function. The compliance boundary is the full chain.

7. Implement Article 50 transparency controls by August 2, 2026. Ensure AI-generated content is identifiable, deepfakes are labeled, and individuals interacting with AI systems are informed. This obligation did not move.

8. Prepare the HRAIS compliance regime by December 2, 2027. The extension gives time to build the risk management system, technical documentation, and post-market monitoring — but the architecture should be designed for it now, not retrofitted later.

The cost of non-compliance vs. the cost of governance

The maximum fine is €35 million or 7 percent of global turnover. For a mid-market company with €100 million in revenue, that is €7 million. The governance layer that satisfies the Act — audit logging, rate limiting, typed errors, kill-switch, module registry, tenant isolation — is the same governance layer that makes production agents safe to operate regardless of regulatory pressure. The 47 to 53 percent of organizations that have already experienced an agent incident are paying the cost of ungoverned agents in operational risk. The Act simply makes that cost explicit and enforceable.

The organizations that built governance into their agent architecture from the start — module registration with schemas, function call logging to a durable store, authentication with short-lived tokens, rate limits enforced at the module boundary — are the ones for whom August 2, 2026 is a transparency documentation exercise and December 2, 2027 is a HRAIS readiness checkpoint, not an emergency retrofit. The organizations that deployed agents as ad-hoc scripts calling APIs directly are the ones facing the emergency — and the transparency deadline is still August 2, 2026.

Update — 2026-08-23: KILLSWITCH.md — the open file convention for Article 14 compliance

KILLSWITCH.md (v1.0, MIT licence) is a new open file convention for AI agent emergency stop protocols, placed in the repository root alongside AGENTS.md. The file defines TRIGGERS (cost limits, error thresholds), FORBIDDEN actions, and a three-level ESCALATION path (throttle → pause → full shutdown with save_state). It is part of a twelve-file "Agentik Safety Framework" (ASF) and explicitly maps to EU AI Act Article 14 — "human oversight and shutdown capabilities for high-risk AI systems."

For EU AI Act compliance, KILLSWITCH.md is the concrete implementation pattern for Article 14's human oversight and shutdown requirement. The file is the auditable evidence that a shutdown protocol exists, is version-controlled, and is reviewable. An auditor reads the file to understand the triggers (cost limits, error thresholds), the forbidden actions (files, APIs, system commands the agent must never touch), and the escalation path (throttle → pause → full shutdown). The three-level escalation maps to the proportionality principle: Article 14 requires oversight proportional to risk, and KILLSWITCH.md's graduated response (throttle for low-risk, pause for medium-risk, full shutdown for high-risk) is the proportionality mechanism. The file convention also maps to Colorado AI Act, California, Texas, and Illinois AI governance laws — all reference "kill switch" and "human override" requirements.

For the compliance timeline, KILLSWITCH.md is a Day 22 (enforcement) implementation: the file can be authored, reviewed, and committed to a repository in hours, providing immediate Article 14 evidence. The EU AI Office is hiring 40 enforcement posts (September 8 deadline — 16 days away). See the Kill Switch by Design article for the four-layer infrastructure architecture that KILLSWITCH.md complements, and the governance checklist for the new checklist item on repository-level emergency-stop specifications.

Update — 2026-08-24: ChatGPT Ads in 31 European markets — Article 50 transparency and ads in AI chatbots

ChatGPT Ads launched in 31 European markets on August 24, 2026, with CPC buying and approximately 20% of ChatGPT queries showing commercial intent. OpenAI's advertising business is approaching a $1B annualized run rate. The expansion into European markets — where the EU AI Act is now enforced — creates an open compliance question: it remains unclear how regulators will approach ads in AI chatbots.

The interaction between ChatGPT Ads and EU AI Act Article 50 transparency obligations is the compliance dimension. Article 50 requires transparency about AI interaction — users must know they are interacting with an AI system. When an AI chatbot serves a paid advertisement, the transparency obligation extends to the ad itself: the user must know the response contains a paid placement, not just that they are chatting with an AI. The EU AI Act does not explicitly address advertising within AI chatbots — this is a gap that regulators will need to clarify. For compliance teams, the question is: if your AI system serves or recommends paid content, does it disclose the paid nature of that content to the user in a way that satisfies Article 50 transparency? This is a new compliance dimension for AI systems that incorporate advertising or paid recommendation layers.

---

A distributor running NetSuite, BigCommerce, and three supplier catalogs has an agent that receives RFQs, resolves products against a catalog graph, prices per customer tier, and writes quotes back to NetSuite. If that agent prices credit terms or selects suppliers for regulated procurement, it falls under the high-risk category. The governed MCP architecture — every tool call logged to DynamoDB with timestamp and outcome, every module disableable by configuration change, every agent authenticated with short-lived JWT tokens, every error typed and classified — is what makes that agent transparent-compliant on August 2, 2026 and HRAIS-ready by December 2, 2027. The same architecture that makes it safe to operate makes it compliant to operate.

Request a scoped build. One-week discovery. You get a system inventory, workflow map, and fixed scope — whether or not you build with us.