Move agents from pilot to production under your own controls.
For enterprises with an agent already in pilot or a committed AI project. We test what you have, build what is missing to a written boundary, and supply a managed team when the work becomes a programme. Each workflow runs inside your identity, data and operating processes.
Who it is for
- CTO and Head of AI
- The technical sponsor. Needs a decision that can be defended on whether to build, and a first version that can be measured.
- AI platform lead
- Has an agent in pilot or production and a decision to make about expanding it. Needs evidence a release decision can rely on.
- Quality and security leads
- Need permission, denied-action and cross-tenant tests run against the authoritative system state, and an evidence pack they can reproduce.
- CIO office
- Needs a programme with named accountability, a written boundary for each workflow, decision gates in the timeline and a tested exit plan.
Enterprise engagements involve more people than the buyer who first agrees to a meeting: a business sponsor, an enterprise architect, a security reviewer, a procurement lead, legal counsel and often an incumbent consultant or integrator. Each needs a different answer. The engagement path below is built around that.
Where enterprises start
Most enterprises start with 01 or 03. Work that grows into a programme moves to 05.
01Workflow architecture and baseline
Start here when the question is whether to build. A recommendation not to build is a valid outcome.
2–3 weeks03Agent release assurance
Start here when an agent already exists and the question is whether to expand it. Covers agents built in-house or by Chainfore.
4–6 weeks02Assured workflow engineering
Build one integrated workflow to a stated boundary, with the controls and evidence needed to run it.
6–10 weeks04Reliability operations
Keep a live workflow dependable as models, tools, data and volumes change.
Monthly05Dedicated engineering delivery
When the work is a programme: a Chainfore-managed team owns a defined workstream inside it.
3–24 monthsExample workflows at enterprise scale
The kind of work this looks like inside a large organisation. In every case, the action that matters stays with a person.
| Workflow | What the system does | What stays with a person |
|---|---|---|
| Release decision for an agent in pilot | Outcome, permission and regression tests against the systems the agent acts on, with repeated trials per task. | The expansion decision, taken by the owner on the evidence. |
| Accounts-payable reconciliation | Matches each invoice line to the purchase order and goods receipt, and proposes an entry for a price difference. | Approval of the exact entry: amount, account and expiry. |
| Market-intelligence analyst in Microsoft Teams | Answers from permitted sources inside your tenant, with each source logged. | Which sources it may use, and who may see them. |
| AI deployment on a private network | Runs in your environment with controlled supplier access. Production access only for named, approved accounts. | Granting and revoking that access. |
| An engineering workstream in a platform programme | A managed team works in your repositories, environments, identity and review process. | Product strategy, roadmap approvals and everything outside the contracted scope. |
How the work runs: the engagement path
Seven stages, each with an exit criterion. A pilot starts only when acceptance criteria and an expansion rule are agreed.
| Stage | Purpose | Exit criterion |
|---|---|---|
| 1. Discover | Find a funded, measurable problem | A named owner and budget, or a funded question |
| 2. Quantify | Put a value on the problem | Baseline cost, failure cost and value of improvement agreed in writing |
| 3. Build the champion | Find an internal sponsor who will drive the decision | Sponsor commits to a next step and names decision-makers |
| 4. Validate the architecture | Satisfy technical reviewers | Enterprise architect accepts the design, access model and test plan |
| 5. Clear security and risk | Satisfy security, legal and procurement | Security review passed or scoped; contract terms agreed in principle |
| 6. Pilot | Prove the result on real work | Acceptance criteria met; expansion decision taken by the agreed rule |
| 7. Expand | Move to recurring use | Second use case or operations contract signed |
Each proposal contains the business problem and its baseline, the workflow and its boundary, the acceptance criteria, the evaluation plan, the security and data controls, the team and named accountabilities, the timeline and decision gates, the commercial terms and the exit terms.
Security: six layers of control
Hosting location alone does not settle who can access data. We document control in six layers and agree each one in the contract.
| Layer | What we implement |
|---|---|
| Deployment boundary | Production, backup, model-provider, log, telemetry and disaster-recovery locations documented. |
| Operator access | Client-approved accounts; least privilege; multi-factor authentication; time-limited access; session logging where appropriate; no shared production credentials. |
| Development data | Synthetic or minimised test data. We do not assume that de-identification removes privacy obligations. |
| Training and retention | No training or product improvement on customer data unless explicitly authorised; model-provider handling, retention and deletion specified. |
| Contracting and IP | Written scope; confidentiality; foreground and background IP; subcontractors; termination assistance; approved data flows. |
| Restricted work | Sector, geography and procurement restrictions checked before access is accepted. We decline work the proposed model cannot lawfully or operationally support. |
Trust and compliance status
| Area | Status |
|---|---|
| Delivery method, failure tests and evaluation standard | In place; applied to each engagement |
| Per-engagement data-flow diagram, threat model and model and provider register | Produced for each engagement |
| Standard security pack for procurement | In progress |
| Confidentiality and IP terms | Standard in our contracts |
| Incident response and vulnerability process | Defined; tested before go-live on each engagement |
| SOC 2 | Not held. A SOC 2 examination report is claimed only when an independent auditor issues one |
| ISO/IEC 42001 | Not held. Pursuing the certification pathway through an accredited body |
| Company registration, tax and insurance details | Supplied during vendor onboarding |
We separate what is in place from what is in progress, and we do not present a plan as a certificate.
Regulatory timeline
Context for planning, not advice. Signals from primary or official sources, checked on 21 October 2026. Live pages can change.
| Regime | Milestone | Source |
|---|---|---|
| EU AI Act, Annex III high-risk obligations | Apply from 2 December 2027 | Regulation (EU) 2026/1744 (AI Omnibus) |
| EU AI Act, Annex I obligations | Apply from 2 August 2028 | Regulation (EU) 2026/1744 |
| EU AI Act, Article 50 transparency | Applies from 2 August 2026, with a marking transition to December 2026 for some systems | Confirm the exact text on EUR-Lex |
| Saudi Arabia, SDAIA National AI Risk Management Framework | Launched 14 July 2026 | Saudi Press Agency |
| UAE AI and Data Authority | Approved 14 June 2026 | UAE Media Office |
| NIST AI Risk Management Framework | Voluntary framework for managing AI risk | NIST |
| ISO/IEC 42001 | AI management system standard; certification only through accredited bodies | ISO |
Regulatory obligations depend on the specific system and its use. These dates indicate when obligations begin. They do not mean every enterprise AI system falls under the same requirements. Customers take legal advice from their own counsel.
What stays the same at every size
- Named people. A technical lead, a delivery lead and a named person for escalations, all named in the proposal.
- A written boundary. What the system may read, which tools it may use and which actions need approval, written down before the build.
- What counts as done, agreed in writing before we build. The result is checked in your own systems, not taken from the AI’s report of what it did.
- A person approves the actions that matter. The software enforces this; it is not left to the AI’s judgement. The system does more on its own only when you agree and the evidence supports it.
- Your data stays yours. No training or product improvement on it unless you explicitly authorise it, and deletion when the work ends.
Related work and clients
Organisations we are permitted to name, and the use cases closest to enterprise work.
| Client | What we did |
|---|---|
| PreScouter | Live in productionChainfore built Auxee for PreScouter: an AI market-intelligence analyst, live in production inside Microsoft Teams, built on Activepieces. |
| PepsiCo | 2025 to February 2026AI work. |
| Sony | A private-network AI deployment, delivered with PreScouter. |
| Saudi Aramco | A private-network AI deployment, delivered with PreScouter. |
We have also worked with Hitachi Rail and Emergent BioSolutions.
Related use cases
Rescue and test an agent stuck in pilot
Test the agent against your systems first, then finish it to a written boundary.
Mid-market · EnterpriseA knowledge analyst inside Microsoft Teams
Answers from the sources you permit, with each source logged. The pattern Chainfore built as Auxee for PreScouter.
Mid-market · EnterpriseQuestions enterprise buyers ask
Do you hold SOC 2 or ISO/IEC 42001?
No. SOC 2 is not held; a SOC 2 examination report is claimed only when an independent auditor issues one. ISO/IEC 42001 is not held; we are pursuing the certification pathway through an accredited body. A standard security pack for procurement is in progress.
Can the work run without access to our production systems?
Yes. In no-production-access engineering we build on synthetic data and customer-run pipelines, and you operate production. Client-hosted and managed-tenant options are also available.
Can you work alongside our incumbent integrator or consultancy?
Yes. Enterprise engagements often include an incumbent consultant or integrator, and dedicated engineering delivery is also designed for delivery leads at consulting firms. Each proposal states who is responsible for each deliverable and each acceptance test.
Do the regulatory dates on this page apply to us?
That depends on the specific system and its use. The dates indicate when obligations begin, not that every enterprise AI system falls under the same requirements. Customers take legal advice from their own counsel.
Bring one workflow, or one agent.
Tell us the process or the agent, the systems involved and the decision in front of you. We will respond with a proposed first step.