AI · Enterprise Systems
The systems already hold the truth. The work is reaching it without breaking anything.
Noble connects models to the systems an organisation already runs on — the ERP where the operational record lives, the CRM, the service desk, the document store, the data platform — so that an assistant answers from the live record, a prediction is served into the screen where the decision is made, and an agent acts through the same released interfaces a person’s application would. The model is never given the database; it is given an interface, an identity and a record.
SAP is named on this page because on an enterprise estate the operational record usually lives there. Where an organisation’s systems are not SAP, the same design applies; the broader systems landscape is Digital Transformation’s subject.
Why the interface, not the database
The fastest way to connect a model to an enterprise system is to point it at the database, and it is the way that fails a year later. A model reading tables directly bypasses every authorisation rule the application enforces, sees data the person asking is not allowed to see, and breaks the day the vendor changes a table. Noble connects through what the system releases — its APIs, its events, its published data views — on an identity created for the purpose, with the permissions of the person the model is serving and no more.
The same discipline decides what is read and what is written. An assistant over the ERP reads through a governed layer — the reconciled record the organisation already trusts for reporting — rather than through a fresh extract that will disagree with it. An agent that writes does so through the transaction the application exposes, so that every posting has the validation, the authorisation and the audit trail the application already provides. The model adds a reader and an actor; it does not add a second way of doing things.
Several systems, one governed layer
The systems an organisation runs on converge on one layer that a model is allowed to reach: permission-aware, built on released interfaces, and recording every read and write against the identity it was made for.
- 01ERP — the operational recordUsually SAP
- 02CRM and customer systemsAccounts, cases, contacts
- 03Service desk and workflowTickets, approvals
- 04Document and content storesWith their permissions
- 05Data platform and metric layerReconciled, governed
What the service covers
Assistants over the live record
An assistant that answers from the system rather than about it: the status of this order, the open items on this account, the policy that applies to this request — read through released interfaces on the person’s permissions, and shown inside the application they are already in. Where SAP provides its own assistant, it is enabled and scoped; where it does not reach, one is built beside it.
- Answers from live records, on the person’s permissions
- Embedded in the application, not beside it
- Vendor assistants enabled and scoped where they exist
- Arabic and English over the same record
Released interfaces, and nothing else
Every read and write goes through what the system publishes — APIs, events, data views — never through its tables. Interfaces are exposed to the model as tools with a schema, a permission and a cost, versioned and retired on notice, so that an upgrade to the enterprise system does not silently break the model, and the model cannot reach what the interface does not offer.
- APIs, events and published views; never the database
- Tools defined with schema, permission and cost
- Versioned, so upgrades do not break the model silently
- Built on the integration layer the estate already has
A bounded identity for the model
The model runs on an identity created for it — not a shared service account, not an administrator — with the permissions of the person it is serving when it reads, and a narrower set when it writes. The identity is provisioned, reviewed and removed through the same joiner, mover and leaver process as a person’s, because an identity that can read the ERP is a user whatever is behind it.
- An identity per model or agent, never a shared account
- Reads on the person’s permissions; writes on a narrower set
- Provisioned and reviewed like a person’s access
Grounded in governed data
Where a model needs history rather than the current record — for a prediction, a trend, a comparison — it reads from the governed layer the organisation already reports from, so its answer agrees with the figure the board saw. No fresh extract, no second version of the truth, and a lineage from the model’s input back to the transaction it came from.
- History read from the governed, reconciled layer
- No second extract that disagrees with the reports
- Lineage from the model’s input to the transaction
Actions through the application’s own transactions
When a model writes — posts the document, updates the case, releases the order — it does so through the transaction the application exposes, so the validation, the authorisation check and the audit entry the application already performs are performed. Every posting is attributable to the model’s identity, and the actions past a defined cost wait for a person, as on the agents page.
- Writes through the transaction, with its validation and audit
- Every posting attributable to the model
- Costly actions wait for a person
The record, and the boundary of the data
Every read and write a model makes against an enterprise system is logged with the identity, the interface, the input and the result, so the organisation can answer what the model saw and did on any day. Residency is decided before a model is chosen — which data may leave the estate, which may reach a model outside the region, and which may not leave the application at all.
- Every read and write logged with identity, input and result
- Residency decided before the model is chosen
- Data that may not leave the application stays in it
Where this connects
- SAP Automation, AI & Intelligent EnterpriseThe SAP side of this subject — what SAP provides, and how automation is applied inside an SAP process. The two pages are written once, from opposite sides.
- SAP BTP, Integration & ExtensionsThe released interfaces, APIs and events a model reaches SAP through are built and governed there.
- AI Agents & Intelligent AutomationThe stopping conditions, budgets and review boundary an acting model runs under are designed there.
The services alongside
- SAPWhere the operational record lives on an enterprise estate, and where prediction and document work find something real to run on.
- Digital TransformationThe wider systems landscape — ERP beyond SAP, the integration across the estate, the master data agreed once — is that service’s subject.
- SecurityThe model’s identity, its permissions and the audit of its actions come from the same identity system as everything else.
SAP and S/4HANA are products of SAP SE, named because the operational record on an enterprise estate usually lives there. All marks belong to their owners.
Name the screen.
The screen where somebody makes a decision with the system open in front of them is where a model earns its place. Name it, and the interfaces it needs can be drawn.