# GenAI Enterprise Application Integration Design: [Programme or application landscape]

> Design document for bringing generative AI assistants and agents into enterprise applications:
> ERP, CRM, IT service management and workplace productivity suites. It records the use case
> portfolio per application, the choice between vendor-native copilots and agents (for example SAP
> Joule, Salesforce Agentforce, Microsoft 365 Copilot and Copilot Studio, and ServiceNow Otto,
> formerly Now Assist) and custom agents on the enterprise AI platform, grounding data and permissions,
> integration points across suites, human oversight, data residency, security, evaluation, licensing
> and cost, regulatory duties under Regulation (EU) 2024/1689 (the AI Act) as amended by Regulation
> (EU) 2026/1744, rollout and risks. Vendor product names change often: check each one at the
> vendor's current documentation. Replace every `[bracketed]` value and every row marked *Example*.
> The regulatory rows are a documentation format, not legal advice.

<!--
Guidance: How to use this template
- Write one design per programme that adds AI to one or more enterprise suites. Each suite's own
  solution design keeps the configuration detail: SAP (`architecture/sap-s4hana-solution-design`),
  Salesforce (`architecture/salesforce-solution-design`), Dynamics 365
  (`architecture/dynamics-365-solution-blueprint`) and ServiceNow
  (`architecture/servicenow-platform-design`).
- Shared platform controls (gateway, retrieval, evaluation, observability) are defined once in the
  enterprise AI platform reference (`architecture/enterprise-ai-platform-reference`). This document
  says how each suite connects to them.
- Start with section 2 (use cases) and section 5 (grounding and permissions). Most failures of
  embedded copilots are oversharing, not model quality.
- Re-check vendor names, licence models and data residency commitments before every release; they
  change several times a year.
-->

## Document control

<!-- Guidance: Identify the suites, tenants and releases in scope. A new suite, a change from vendor-native to custom (or back) or a new autonomy level is a new major version. -->

| Field | Value |
|---|---|
| Document ID | [GEI-001] |
| Programme | [Name] |
| Applications and tenants in scope | [ERP tenant], [CRM org], [ITSM instance], [Productivity tenant] |
| Vendor AI products in scope | [Product names and editions, as named in the contract] |
| Target releases | [Vendor release per suite] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@enterprise-architect] |
| Approvers/reviewers | [@application-owners], [@ciso], [@data-protection-officer], [@ai-governance-lead], [@procurement] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| Business sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Application owners | [@name] | [Decision] | YYYY-MM-DD |
| Security | [@name] | [Decision] | YYYY-MM-DD |
| Data protection | [@name] | [Decision] | YYYY-MM-DD |
| AI governance board | [@name] | [Decision] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft |
| 1.0 | YYYY-MM-DD | [@name] | *Example:* Approved for CRM service agent and ITSM incident summarisation |
| 1.1 | YYYY-MM-DD | [@name] | *Example:* Added ERP finance assistant and cross-suite hand-off |

## Contents

<!-- Guidance: Keep this list aligned with the headings. -->

1. [Scope and context](#1-scope-and-context)
2. [Use case portfolio](#2-use-case-portfolio)
3. [Vendor-native or custom](#3-vendor-native-or-custom)
4. [Vendor capability baseline](#4-vendor-capability-baseline)
5. [Grounding data and permissions](#5-grounding-data-and-permissions)
6. [Integration points](#6-integration-points)
7. [Human oversight and autonomy](#7-human-oversight-and-autonomy)
8. [Data residency and processing](#8-data-residency-and-processing)
9. [Security](#9-security)
10. [Evaluation and acceptance](#10-evaluation-and-acceptance)
11. [Licensing and cost](#11-licensing-and-cost)
12. [Regulatory and governance duties](#12-regulatory-and-governance-duties)
13. [Rollout and adoption](#13-rollout-and-adoption)
14. [Risks and traceability](#14-risks-and-traceability)
15. [Glossary and references](#15-glossary-and-references)

## 1. Scope and context

<!-- Guidance: State the business outcomes, the suites and the user groups. Questions: which processes should change, and how will you know? Which suites are systems of record for the data the AI will read? Pitfall: a programme scoped as "switch on the copilot" with no process outcome. -->

### 1.1 Outcomes

| ID | Outcome | Baseline | Target | Measured by |
|---|---|---|---|---|
| GEI-OUT-001 *(Example)* | Faster first response on customer cases | [4 h median] | [1 h median] | CRM case reports |
| GEI-OUT-002 *(Example)* | Fewer incident tickets reach level 2 | [38 %] | [28 %] | ITSM reassignment reports |
| GEI-OUT-003 *(Example)* | Shorter month-end close for accounts payable | [6 days] | [4 days] | Close calendar |
| [GEI-OUT-NNN] | [Outcome] | [Baseline] | [Target] | [Source] |

### 1.2 Landscape

| Suite | Role | System of record for | Users in scope | AI product licensed |
|---|---|---|---|---|
| ERP *(Example)* | Finance and procurement | Suppliers, invoices, purchase orders, ledger | 450 finance users | [Vendor ERP assistant and agents] |
| CRM *(Example)* | Sales and service | Accounts, contacts, cases, opportunities | 1,200 service agents, 300 sellers | [Vendor CRM agents] |
| ITSM *(Example)* | IT and HR service | Incidents, requests, knowledge, configuration items | 250 IT agents; all employees as requesters | [Vendor ITSM assistant] |
| Productivity *(Example)* | Mail, documents, meetings | Files and messages | 6,000 employees | [Productivity suite copilot] |
| [Suite] | [Role] | [Data] | [Users] | [Product] |

## 2. Use case portfolio

<!-- Guidance: List each use case per application with its value, data and risk. Questions: is the AI reading, drafting or acting? Which records can it change? Pitfall: counting demos as use cases; each row needs an owner and a measure. -->

| ID | Application | Use case | Mode | Data read | Records changed | Value measure | Risk tier | Owner |
|---|---|---|---|---|---|---|---|---|
| UC-001 *(Example)* | CRM | Case summary and reply draft for service agents | Draft | Case, emails, knowledge | None (agent sends) | Handle time | Low | [@service-owner] |
| UC-002 *(Example)* | CRM | Customer-facing service agent for order status | Act | Orders, cases, knowledge | Case create, callback | Containment rate | Medium | [@service-owner] |
| UC-003 *(Example)* | ITSM | Incident summary and resolution suggestion | Draft | Incident, similar incidents, knowledge | Work note | Mean time to resolve | Low | [@itsm-owner] |
| UC-004 *(Example)* | ITSM | Password and access request agent for employees | Act | Identity directory, catalogue | Request, group membership | Requests fulfilled without agent | Medium | [@itsm-owner] |
| UC-005 *(Example)* | ERP | Invoice exception explanation for AP clerks | Read | Invoices, purchase orders, goods receipts | None | Exceptions cleared per day | Low | [@ap-lead] |
| UC-006 *(Example)* | ERP | Supplier payment run proposal | Act with approval | Open items, supplier master | Proposal only; release stays manual | Close days | High | [@treasury-lead] |
| UC-007 *(Example)* | Productivity | Meeting summaries and follow-up drafts | Draft | Meetings, chat, files | None | Survey time saved | Low | [@workplace-owner] |
| [UC-NNN] | [App] | [Use case] | [Read / Draft / Act / Act with approval] | [Data] | [Records] | [Measure] | [Tier] | [@owner] |

Prioritise with three questions: does the use case change a measured outcome from section 1.1, is
the data it needs clean and correctly permissioned today, and can a person check its output faster
than doing the work. Defer use cases that fail the second question until the data work is done.

## 3. Vendor-native or custom

<!-- Guidance: Decide per use case whether to use the suite's own copilot or agent, build a custom agent on the enterprise AI platform, or combine them. Questions: does the use case stay inside one suite? Does it need data the vendor cannot reach? Pitfall: building a custom agent for a task the suite already does well, or forcing a vendor agent to orchestrate across five other suites. -->

### 3.1 Decision criteria

| Criterion | Favours vendor-native | Favours custom on the platform |
|---|---|---|
| Process scope | Task lives inside one suite and its data model | Task spans several suites or external systems |
| Data access | Data is already in the suite, with its sharing model | Data sits in many sources with different permission models |
| Time to value | Feature exists and needs configuration | Feature does not exist or needs deep change |
| Control | Vendor's model choice, guardrails and logging are acceptable | Model choice, prompts, evaluation and logs must be owned |
| Cost shape | Licence or consumption price is predictable at the expected volume | Token cost on the platform is lower at the expected volume |
| Portability | Lock-in to the suite is acceptable for this process | Process may move between suites |
| Upgrade cadence | Vendor releases are absorbed by regression tests | Release timing must be controlled |

### 3.2 Worked scoring example

*Example* for UC-002 (customer-facing service agent). Weights sum to 100; scores run from 1 (poor)
to 5 (strong); the weighted total is the sum of weight times score, divided by 100. Agree the
tie rule before scoring: totals within 0.10 of each other are treated as a tie and decided by the
control and portability criterion.

| Criterion | Weight | Vendor-native | Custom | Hybrid (vendor agent plus platform tools) |
|---|---|---|---|---|
| Fit to process | 25 | 4 | 3 | 4 |
| Data access and permissions | 20 | 5 | 3 | 4 |
| Time to value | 15 | 5 | 2 | 4 |
| Cost at expected volume | 15 | 3 | 4 | 3 |
| Control and portability | 15 | 2 | 5 | 4 |
| Vendor roadmap risk | 10 | 3 | 4 | 3 |
| Weighted total (of 5) | 100 | 3.80 | 3.40 | 3.75 |

Check: vendor-native is (25 x 4 + 20 x 5 + 15 x 5 + 15 x 3 + 15 x 2 + 10 x 3) / 100 = 380 / 100 =
3.80; custom is (75 + 60 + 30 + 60 + 75 + 40) / 100 = 3.40; hybrid is (100 + 80 + 60 + 45 + 60 +
30) / 100 = 3.75. Vendor-native and hybrid are 0.05 apart, inside the agreed 0.10 tie band, so the
control and portability criterion decides (hybrid 4 against vendor-native 2): the *Example*
decision is hybrid, which also lets the order status tool be reused by two other channels. Record the decision in the decision log
(`architecture/architecture-decision-log`) and the wider sourcing case with the build vs buy
analysis (`architecture/build-vs-buy-analysis`).

### 3.3 Decisions per use case

| Use case | Decision | Reason | Revisit when |
|---|---|---|---|
| UC-001 *(Example)* | Vendor-native | Data and task inside CRM | Reply quality below target for two months |
| UC-002 *(Example)* | Hybrid | Vendor agent for the channel; order status tool on the platform reused elsewhere | Vendor adds equivalent connector |
| UC-003 *(Example)* | Vendor-native | Incidents, similar incidents and knowledge all live in the ITSM suite | Suggestion match rate below EVL-003 threshold for a quarter |
| UC-004 *(Example)* | Vendor-native with directory workflow | Catalogue and fulfilment workflow already in ITSM; directory changes go through the existing approval workflow (INT-003) | Directory or identity governance tool replaced |
| UC-005 *(Example)* | Vendor-native | ERP assistant reads the documents in context | Need for cross-ERP analysis |
| UC-006 *(Example)* | Custom with ERP approval step | High risk; must own evaluation and logs | Never without governance review |
| UC-007 *(Example)* | Vendor-native | Meetings, chat and files are in the productivity suite | Grounding exposure found in persona tests |
| [UC-NNN] | [Decision] | [Reason] | [Trigger] |

## 4. Vendor capability baseline

<!-- Guidance: Record what each vendor's AI offers at the release in scope, in your own words, with the page and date you checked. Questions: which features are generally available and which are preview? Which can be switched off? Pitfall: designing around a keynote announcement that is not yet in your contract or region. -->

The table lists the main product families as named on vendor pages checked in October 2026. Names
and packaging change often; confirm against the vendor documentation and your order form.

| Suite | Vendor AI products (as named by the vendor) | Grounding mechanism | Extension and build tools | Notes to verify |
|---|---|---|---|---|
| SAP | Joule (assistant), Joule Agents | SAP business data and APIs; SAP Business Data Cloud and SAP Knowledge Graph for semantic context | Joule Studio, SAP Business AI Platform (formerly SAP Business Technology Platform) | Availability per product and region; commercial model under SAP Business AI terms |
| Salesforce | Agentforce, with the Atlas Reasoning Engine | CRM data and Data 360 | Agent Builder, Agent Script, MCP support, multi-agent orchestration | Pricing through Flex Credits, per-resolution or per-user options; default enablement settings per release |
| Microsoft | Microsoft 365 Copilot, Microsoft Copilot Chat, Copilot in Dynamics 365, Copilot Studio agents and workflows | Microsoft Graph and Work IQ, scoped to the signed-in user's permissions | Copilot Studio (agents, workflows, agent flows, connectors) | Licence tier decides work-data grounding; usage-based billing for some agents; harness choice affects billing; Microsoft Agent 365 as the agent registry and governance control plane (separate licence) |
| ServiceNow | ServiceNow Otto (formerly Now Assist; announced 5 May 2026 as one AI experience that brings together Now Assist, Moveworks and AI Experience), AI Agents, AI Specialists | Platform records, knowledge, AI Search | AI Agent Studio, AI Skill Kit, MCP and A2A support | Assist consumption metering; AI Control Tower and AI Guardian for governance; rename rolling out across products, and Now Assist SKU names may remain in order forms |
| [Suite] | [Products] | [Grounding] | [Tools] | [Notes] |

For each product in scope record: general availability or preview status in your region, whether it
is on by default after an upgrade, the admin switch that disables it, the model providers and
subprocessors the vendor lists, and the audit log it produces.

## 5. Grounding data and permissions

<!-- Guidance: Decide what each assistant may read, and prove that it cannot read more than the user. Questions: which sites, libraries, objects or tables are in scope? How is oversharing found and fixed before launch? Pitfall: switching on a workplace copilot over years of overshared files. -->

Embedded copilots answer from what the signed-in user can access. That makes existing oversharing
visible: a file shared with "everyone" five years ago becomes an answer today. Treat permission
hygiene as a launch prerequisite.

| ID | Source | Suite | Permission model | Known exposure | Remediation before launch | Owner |
|---|---|---|---|---|---|---|
| GRD-001 *(Example)* | Shared document sites | Productivity | Site membership, sharing links | 140 sites shared with all employees | Review owners; restrict discovery for sensitive sites during review; apply sensitivity labels | [@workplace-owner] |
| GRD-002 *(Example)* | CRM cases and emails | CRM | Role hierarchy, sharing rules | Service agents see all regions | Restrict by region before the agent is enabled | [@crm-owner] |
| GRD-003 *(Example)* | HR knowledge articles | ITSM | Knowledge user criteria | Two HR bases readable by all IT agents | Correct user criteria | [@hr-it-owner] |
| GRD-004 *(Example)* | Supplier bank details | ERP | Authorisation objects | None found | Exclude fields from AI context explicitly | [@erp-security] |
| [GRD-NNN] | [Source] | [Suite] | [Model] | [Exposure] | [Remediation] | [@owner] |

Rules for grounding:

- Exclude fields that the AI never needs (bank accounts, national identifiers, health data) using the
  suite's masking or field-level controls, even when the user may see them.
- Keep the vendor's grounding inside its own suite. Reach other suites through governed tools (APIs,
  MCP servers or agent hand-offs) that apply the target suite's permissions, not by copying data into
  the vendor's index.
- Review sensitivity labels and retention policies, so that labelled content is handled as designed in
  answers, summaries and generated files.
- Test with real personas: run the same questions as users in different roles and compare what each
  one sees.

## 6. Integration points

<!-- Guidance: Show how AI in one suite reaches data or actions in another, and through which controls. Questions: who calls whom, under which identity? Where is the action logged? Pitfall: point-to-point connectors created by each vendor's agent builder with service-account credentials. -->

| ID | From | To | Pattern | Identity used | Protocol or interface | Logged in |
|---|---|---|---|---|---|---|
| INT-001 *(Example)* | CRM service agent | ERP order status | Tool call through the enterprise AI platform | Agent identity with delegated customer context | MCP server over the ERP order API | Platform trace, ERP API log |
| INT-002 *(Example)* | Productivity copilot | ITSM | Vendor connector for knowledge and incidents | Signed-in user | Vendor connector, ITSM REST API | Both suites' audit logs |
| INT-003 *(Example)* | ITSM agent | Identity directory | Request fulfilment workflow | Workflow service identity with approval | Directory API | ITSM workflow log, directory audit |
| INT-004 *(Example)* | ERP assistant | Custom treasury agent | Agent hand-off | Agent identity | A2A specification 1.0.1 | Platform trace |
| [INT-NNN] | [From] | [To] | [Pattern] | [Identity] | [Interface] | [Logs] |

```mermaid
sequenceDiagram
  participant U as Service agent user
  participant C as CRM agent
  participant P as AI platform tools
  participant E as ERP API
  U->>C: Ask for order status of case
  C->>C: Read case and customer
  C->>P: Call order status tool with case context
  P->>P: Check tool policy and caller scope
  P->>E: Query order with delegated token
  E-->>P: Order status
  P-->>C: Status and source reference
  C-->>U: Draft reply with citation
  U->>C: Approve and send
```

Use the integration strategy (`architecture/integration-strategy`) for the general interface rules,
and the MCP server specification (`ai-data/mcp-server-spec`) for each tool the platform exposes.

## 7. Human oversight and autonomy

<!-- Guidance: Decide, per use case, what the AI may do without a person. Questions: which actions are irreversible? Who reviews outputs after the fact, and how often? Pitfall: an approval step that users click through without reading because the volume is too high. -->

| Use case | Autonomy | Human step | Reviewer | Volume check | Escalation |
|---|---|---|---|---|---|
| UC-001 *(Example)* | Draft | Agent edits and sends | Service agent | n/a | Supervisor review of [2 %] sample weekly |
| UC-002 *(Example)* | Act within limits | Hand-off on low confidence, complaint or request | Service queue | Hand-off rate under [20 %] | Live agent within [2 min] |
| UC-004 *(Example)* | Act with approval for privileged groups | Approver confirms membership in privileged groups | Group owner | Under [30] approvals per approver per day | IT security on denial |
| UC-006 *(Example)* | Propose only | Treasury releases the payment run under the two-person rule | Treasury | Every run | CFO on variance above [threshold] |
| [UC-NNN] | [Level] | [Step] | [Reviewer] | [Check] | [Path] |

Design oversight in detail with the human oversight design (`ai-data/human-oversight-design`), and
record agent behaviour in an AI agent specification (`ai-data/ai-agent-spec`) per custom agent.

## 8. Data residency and processing

<!-- Guidance: Record where prompts, grounding data, outputs and logs are processed and stored for each product. Questions: does the vendor route model calls outside the region under load? Which subprocessors handle prompts? Pitfall: assuming the suite's data residency also covers its AI features. -->

| Product | Tenant region | Model processing location | Subprocessors for AI | Storage of prompts and outputs | Retention | Contract reference |
|---|---|---|---|---|---|---|
| Productivity copilot *(Example)* | EU | Within the vendor's EU data boundary for EU users, per vendor documentation | As listed by the vendor; check additional model subprocessors and their default state | Within tenant, per vendor terms | Per tenant retention policies | [DPA, product terms] |
| CRM agents *(Example)* | EU | [Region per vendor documentation] | [List] | [Location] | [Period] | [Reference] |
| ITSM assistant *(Example)* | EU | [Region] | [List] | [Location] | [Period] | [Reference] |
| [Product] | [Region] | [Location] | [List] | [Location] | [Period] | [Reference] |

Check each product's documentation for overflow routing (calls sent to other regions when capacity
is short), the list of model subprocessors, and whether customer data is used to train models. For
EU personal data, update the record of processing (`compliance/gdpr-ropa`) and run or update the DPIA
(`compliance/dpia`). Assess sovereignty requirements with the data residency and sovereignty
assessment (`compliance/data-residency-sovereignty-assessment`).

## 9. Security

<!-- Guidance: Treat every record, email and document the AI reads as untrusted input. Questions: can an attacker plant instructions in a case, an email or a knowledge article? Which agent identities have write access? Pitfall: agent users created with administrator profiles "to make it work". -->

| ID | Threat | Example in this landscape | Control |
|---|---|---|---|
| SEC-001 *(Example)* | Indirect prompt injection | Customer email in a case tells the agent to issue a refund | Vendor and platform injection guards; refund action not available to the agent |
| SEC-002 *(Example)* | Excessive agent privileges | Agent user with broad object permissions | Dedicated agent identities with least privilege; quarterly access review (`ops/access-review`) |
| SEC-003 *(Example)* | Data leakage through outputs | Summary includes masked fields | Field exclusion from AI context; output checks for identifiers |
| SEC-004 *(Example)* | Shadow agents | Business users publish agents with personal connections | Maker environments, data loss prevention policies, agent inventory |
| SEC-005 *(Example)* | Connector credential abuse | Shared service credentials in a cross-suite connector | Delegated tokens; secrets in a vault; connector review |
| [SEC-NNN] | [Threat] | [Example] | [Control] |

Threat-model each acting agent with the agentic threat model (`ai-data/agentic-threat-model`) and
assess each vendor's AI terms with the AI vendor risk questionnaire
(`compliance/ai-vendor-risk-questionnaire`).

## 10. Evaluation and acceptance

<!-- Guidance: Define how you test vendor AI you cannot change and custom AI you can. Questions: what test set represents real cases? What happens when a vendor release changes behaviour? Pitfall: accepting a vendor feature on a demo and never measuring it again after upgrades. -->

| ID | Use case | Test set | Metric | Acceptance threshold | When run |
|---|---|---|---|---|---|
| EVL-001 *(Example)* | UC-001 | [300] closed cases with approved replies | Reviewer rating of drafts (1 to 5) | Mean at least [4.0] | Before launch, after each vendor release |
| EVL-002 *(Example)* | UC-002 | [500] scripted customer conversations, including [50] adversarial | Task success; unsafe action count | At least [85 %]; 0 unsafe | Before launch, monthly sample |
| EVL-003 *(Example)* | UC-003 | [200] resolved incidents | Suggestion matches the actual fix | At least [60 %] | Before launch, quarterly |
| EVL-004 *(Example)* | All | Persona permission tests from section 5 | Answers expose no data beyond the persona's access | 0 exposures | Before launch, after permission changes |
| EVL-005 *(Example)* | UC-004 | [150] scripted access requests, including [20] for privileged groups | Correct fulfilment; privileged requests routed to approval | At least [95 %]; 100 % of privileged requests routed | Before launch, after each vendor release |
| EVL-006 *(Example)* | UC-005, UC-006 | [300] historical invoice exceptions and [12] past payment runs | Explanation matches the AP clerk's root cause; proposal matches the released run | At least [80 %]; every proposal difference explained | Before launch, quarterly |
| [EVL-NNN] | [Use case] | [Set] | [Metric] | [Threshold] | [Cadence] |

Vendors update models and prompts without your release. Schedule regression runs in each suite's
release calendar (preview sandboxes where the vendor offers them) and use the suite's own evaluation
tools where they exist. Plan the method with the LLM evaluation plan (`ai-data/llm-evaluation-plan`)
and the agent evaluation plan (`ai-data/agent-evaluation-plan`).

## 11. Licensing and cost

<!-- Guidance: Model the full cost per use case, including licences, consumption, platform tokens and the people who review outputs. Questions: which licence model applies (per user, per conversation or resolution, credits)? What happens to cost if adoption doubles? Pitfall: buying per-user licences for everyone before usage is proven. -->

### 11.1 Licence models in scope

| Product | Licence model | Unit | Commitment | Overage behaviour |
|---|---|---|---|---|
| [Productivity copilot] | Per user per month, plus usage-based billing for some agents | User; credits | [Annual] | [Billed / blocked] |
| [CRM agents] | Consumption credits, per resolution or per user (options per contract) | Credit; resolution | [Pre-purchased] | [Billed at rate] |
| [ITSM assistant] | Subscription with an assist allowance | Assist | [Annual allowance] | [True-up] |
| [ERP assistant] | Per the vendor's AI commercial terms | [Unit] | [Terms] | [Behaviour] |
| Custom agents on the platform | Token cost via the gateway | Token | None | Budget alerts |

### 11.2 Worked cost example

*Example*, using illustrative unit prices that are not vendor list prices.

| Use case | Option | Volume per month | Unit price | Cost per month |
|---|---|---|---|---|
| UC-001 | Per-user add-on for 600 service agents | 600 users | USD 30 per user | USD 18,000 |
| UC-002 | Consumption per resolved conversation | 20,000 conversations | USD 0.80 per conversation | USD 16,000 |
| UC-002 | Platform tools called by the vendor agent | 20,000 tool calls x 3,000 tokens = 60 million tokens | USD 4.00 per million tokens | USD 240 |
| UC-006 | Custom agent on the platform | 400 runs x 50,000 tokens = 20 million tokens | USD 4.00 per million tokens | USD 80 |
| Total | | | | USD 34,320 |

The sum is 18,000 + 16,000 + 240 + 80 = USD 34,320. Licence and consumption charges dominate; token
cost on the platform is under 1 % of the total, so negotiate the vendor commercial terms first.
Compare against the value: if UC-002 contains [6,000] contacts per month that previously cost [USD 4]
each, it saves [USD 24,000] against USD 16,240 of cost. Add the cost of review time and of the
evaluation runs. Model the full lifecycle in the TCO analysis (`architecture/tco-analysis`).

## 12. Regulatory and governance duties

<!-- Guidance: Map each use case to the duties that apply to the organisation as deployer of vendor AI, or as provider of custom AI. Questions: is any use case high-risk under Annex III (for example employment decisions or creditworthiness)? Are people told they are talking to AI? Pitfall: assuming the vendor carries all obligations. -->

Dates follow Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744; check the
consolidated text on EUR-Lex.

| Duty | Article | Applies from | Use cases affected | Evidence |
|---|---|---|---|---|
| AI literacy measures for staff using the tools (wording amended by 2026/1744) | Article 4 | 2 February 2025 | All | Literacy plan (`ai-data/ai-literacy-plan`) |
| Disclosure that people interact with an AI system: provider duty (the vendor for vendor-native agents, the organisation for custom agents); deployer duties for deep fakes and emotion recognition where applicable | Article 50(1); Article 50(3) and 50(4) | 2 August 2026 | UC-002, UC-004 | Vendor disclosure design, disclosure text and screenshots |
| Deployer duties for high-risk systems | Article 26 | 2 December 2027 for Annex III systems | [Only if a use case is high-risk, for example HR screening] | Oversight design, logs, monitoring |
| Fundamental rights impact assessment | Article 27 | 2 December 2027 for the Annex III systems it covers | [If applicable] | FRIA (`ai-data/ai-act-fria`) |
| Personal data processing | GDPR Articles 6, 30 and 35 | In force | All using personal data | Record of processing, DPIA |

Register each use case in the AI use case intake (`ai-data/ai-use-case-intake`) and the regulatory
applicability register (`compliance/ai-regulatory-applicability-register`). A custom agent that the
organisation builds and places in service under its own name may make the organisation a provider for
that system; record that analysis.

## 13. Rollout and adoption

<!-- Guidance: Plan waves that prove value and safety before scale. Questions: who are the pilot users? What must be true to widen the rollout? Pitfall: a big-bang licence purchase followed by low adoption. -->

| Wave | Scope | Users | Entry criteria | Exit criteria | Target date |
|---|---|---|---|---|---|
| W0 *(Example)* | Permission remediation (section 5) | None | Approved design | GRD items closed; persona tests pass | YYYY-MM-DD |
| W1 *(Example)* | UC-001, UC-003 | 50 service agents, 20 IT agents | W0 complete | EVL-001 and EVL-003 met; adoption at least [60 %] of pilot users | YYYY-MM-DD |
| W2 *(Example)* | UC-002 in one market | Customers of [market] | Disclosure live; hand-off tested | EVL-002 met for four weeks | YYYY-MM-DD |
| W3 *(Example)* | All markets; UC-005 | All service and AP users | W2 exit | Outcome targets trending to 1.1 values | YYYY-MM-DD |
| [W-N] | [Scope] | [Users] | [Entry] | [Exit] | YYYY-MM-DD |

Support adoption with role-based training, prompt guidance in the users' language, champions per
team, and a feedback channel whose items are triaged weekly. Track active users, outputs accepted
without edit, hand-off rates and complaints per use case.

## 14. Risks and traceability

<!-- Guidance: Keep the risks that would stop the programme and trace outcomes to use cases, tests and evidence. Pitfall: risks copied from a vendor slide with no owner. -->

| ID | Risk | Likelihood | Impact | Mitigation | Owner |
|---|---|---|---|---|---|
| GEI-R-001 *(Example)* | Oversharing exposed through copilot answers | High | High | Section 5 remediation as a launch gate | [@workplace-owner] |
| GEI-R-002 *(Example)* | Vendor release changes agent behaviour | Medium | Medium | Regression runs in the release calendar | [@application-owners] |
| GEI-R-003 *(Example)* | Consumption cost exceeds budget | Medium | Medium | Monthly cost review; caps where the vendor supports them | [@finops-lead] |
| GEI-R-004 *(Example)* | Overlapping agents in several suites answer the same request differently | Medium | Medium | One owning suite per process; hand-off rules | [@enterprise-architect] |
| GEI-R-005 *(Example)* | Product renames and repackaging break contract assumptions | Medium | Low | Contract names products by function and SKU; annual review | [@procurement] |
| [GEI-R-NNN] | [Risk] | [L] | [I] | [Mitigation] | [@owner] |

| Outcome | Use cases | Tests | Evidence |
|---|---|---|---|
| GEI-OUT-001 *(Example)* | UC-001, UC-002 | EVL-001, EVL-002 | Case reports before and after W2 |
| GEI-OUT-002 *(Example)* | UC-003, UC-004 | EVL-003, EVL-005 | Reassignment reports |
| GEI-OUT-003 *(Example)* | UC-005, UC-006 | EVL-006 | Close calendar |
| [GEI-OUT-NNN] | [Use cases] | [Tests] | [Evidence] |

## 15. Glossary and references

<!-- Guidance: Define vendor-neutral terms and list the vendor pages with the date you checked them. -->

| Term | Meaning in this document |
|---|---|
| Copilot | Assistant embedded in an application that drafts, summarises or answers in context |
| Agent | AI component that plans steps and calls tools to complete a task, possibly changing records |
| Grounding | Supplying the model with enterprise data relevant to the request |
| Hybrid | Vendor-native agent that calls tools or agents hosted on the enterprise AI platform |
| Oversharing | Content accessible to more people than its owner intends |

| Reference | Version or date checked | Use |
|---|---|---|
| Microsoft Learn, What is Microsoft Copilot (Microsoft 365 Copilot overview) | Page dated 2026-10-20 | Grounding, licences, EU Data Boundary |
| Microsoft Learn, Microsoft Copilot Studio overview | Page dated 2026-09-25 | Agents, workflows, harnesses |
| Salesforce, Agentforce product page | Checked 2026-10-23 | Agentforce, Atlas Reasoning Engine, pricing options |
| SAP News Center, SAP Connect keynote: autonomous enterprise in action | October 2026 | Joule, Joule Agents, Joule Studio, Business Data Cloud, Knowledge Graph |
| ServiceNow press release, "ServiceNow Otto creates the unified AI experience for the enterprise", newsroom.servicenow.com | 5 May 2026 | Otto naming and scope |
| ServiceNow Store release notes, ITSM AI applications, and ServiceNow Community articles | Checked 2026-10-23 | In-product rename, AI Agents, AI Control Tower, AI Guardian |
| Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, EUR-Lex | Consolidated text, check before use | Section 12 |
| A2A Protocol Specification, a2a-protocol.org and github.com/a2aproject/A2A | 1.0.1 (May 2026, a patch release of 1.0.0; protocol version `1.0`; the specification site labels 1.0.0 as the latest release) | Section 6 |

## Standard and licence note

Based on the public product documentation of the vendors named above (checked in October 2026) and
on Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744 (EU legislative texts are free
to reuse). Vendor features are described in original wording for mapping only, and no vendor text,
checklist or diagram is reproduced. The structure, criteria and examples are original to this
collection. Check the current vendor documentation, your contracts and the consolidated legal text
before use. The regulatory rows are a documentation format, not legal advice. SAP, Joule, Salesforce,
Agentforce, Microsoft, Microsoft 365 Copilot, Copilot Studio, Dynamics 365, Microsoft Agent 365, ServiceNow, Otto and Moveworks
are trademarks of their owners; this template is not affiliated with or endorsed by them. Template
licence: MIT.