Legacy SAP Estates and Agent Integration

The integrator's slide said 'native SAP AI'. The plant's landscape was ECC 6.0 with a half-finished S/4 migration, a custom Z-table for railway rakes, and a middleware box nobody wanted to reboot. The vendor asked for a service account with SAP_ALL so the agent could 'discover the processes'. The BASIS lead, who had survived two audits of that box, closed the laptop.

This guide is for the SI and the PSU IT lead who have to put an agent next to a living SAP estate. It is not a catalogue of module APIs. We will not invent MM, PM, FICO or IS-Oil endpoints that your release may not expose. The honest integration is a short list of connectors the estate already owns, a purpose tag on every call, and a hard ban on unattended postings.

SAP landscapes in maharatnas are political objects. The AMS partner, the licence metric, the custom code, and the plant that still runs a batch at 2 a.m. all have owners. An agent that pretends those owners do not exist will be treated as a shadow interface. Shadow interfaces are how you get a para and a downtime in the same quarter.

Not legal advice and not SAP implementation advice. Read your current release notes, the AMS contract, the SoD matrix, and counsel before you mint a service user.

Connectors you already have — not invented module APIs

Start from the interfaces the estate already documents: IDocs that leave for a bank, RFCs the middleware already calls, OData services the Fiori team exposed, files the reconciliation job already drops, and the reporting extract the data warehouse already trusts. If a movement is not on that list, the agent does not get a new private API in week one.

Do not write a tender that says 'integrate with SAP MM, PM, FICO, HCM, SRM, IS-Oil and TM' as if those were sockets. Those are product families. Your system may be ECC, S/4, a mix, or a third-party storefront in front of a core that is older than the SI's current staff. Name the system ID, the client, the interface type, and the transaction or service the business already uses.

Purpose tags sit on the call, not on the slide. 'Invoice-exception retrieval for plant accounts' is a purpose. 'SAP access' is not. DPDP cares about purpose when the payload identifies a person — a vendor's authorised signatory, an employee's travel claim, a pensioner's account. The same tag helps SoD: a retrieval purpose must not quietly become a posting purpose.

Score the interface you can name. Refuse the interface the brochure implies.

What the bid says	What the file should name	Fail if
Native SAP integration	SID, client, interface type, existing service or file, AMS owner	The only artefact is a module acronym
Read-only copilot	The exact queries or extracts, the SoD role, the non-prod proof	The service user can SM30, SCC4 or post
Purpose-limited	A purpose string on every call, logged with the user and the object	Purpose is a paragraph in the proposal
Works with S/4 and ECC	Which landscape this plant is actually on this quarter	The demo was on a fresh S/4 cal tenant

Service users, SoD, and the posting ban

A dedicated service user with a retrieval role is a controllable object. SAP_ALL is a finding waiting for IA. Copy the role from the clerk the agent is helping, then strip every write. Prove the strip in a non-production client with the same custom objects. Custom Z-transactions are where PSU estates hide the real risk.

Unattended posting is how an agent becomes a cashier. Goods movements, invoice blocks, payment proposals, vendor master changes and HR actions stay with a named dialog user. The agent may draft. The user posts. If the business wants straight-through processing later, that is a separate change with a separate SoD review, not a flag on the copilot.

Keep OT networks out of this conversation. Plant historians, DCS and safety systems are not SAP. If someone proposes to 'enrich' a PM notification with a live tag from the historian, read the companion note on why agents stay off OT. The ERP is already enough surface.

Where the payload lives

Prompts that paste a vendor invoice, a cancelled cheque, or a travel claim are payment-adjacent or personal. Do not send them to a foreign model host because the SAP GUI is on-prem. Inference location is independent of the ERP location. The conservative PSU file keeps embeddings and traces on the company's side of the firewall and writes a training ban.

CERT-In's 180-day ICT log floor applies to the agent hosts. SAP's own change documents are not a substitute for the agent's retrieval set. You need both: the ERP's change doc if a human posted, and the agent's packet if a draft was proposed.

The AMS partner is in the room whether you invite them or not

Most PSU SAP estates have an application-management partner with a change calendar, a transport path, and a commercial interest in not being surprised. An agent project that bypasses them will stall at the first transport. Write a joint RACI: who mints the role, who reviews the custom-code touch, who owns the interface after go-live, who pays for the extra sandbox.

If the AMS partner wants to productise their own copilot, score it on the same connector and purpose tests. Incumbency is not a technical score. It is a mobilisation fact.

Objections you will hear — and what to do with them

These are the lines that stall the file. Answer them in the room, then put the answer in the note. A spoken answer without paper will be forgotten by the next officer.

We need SAP_ALL in the sandbox to explore.

Explore with a named BASIS user on a ticket, not with the agent's service user. Habits leak from sandbox to production. The role you test is the role you ship.

Our hyperscaler has a certified SAP connector.

Certification is about the pipe. It is not a purpose tag, a residency decision, or a posting ban. Ask where inference runs and who can read the payload. Then look at the connector.

The business wants the agent to park invoices.

Parking is a posting. Put it on a later change with SoD, a limit, and a named fallback. Do not hide it inside 'read-only copilot' because the demo looked gentle.

Custom Z-code is undocumented, so we will let the model read the ABAP.

Reading ABAP in a vendor-hosted model is how your rake logic leaves the building. If you must analyse custom code, do it on a dark copy with a training ban. Prefer the functional owner over the model.

A four-week integration playbook

This is discovery you can put in a minute. It is not a full S/4 programme.

1. Week 1: inventory SID, clients, AMS owner, and every interface already in the landscape register. Mark which ones the use case actually needs. Kill the module-acronym list.
2. Week 2: design a retrieval-only role from the clerk the agent will help. Strip writes. Test in the plant's non-prod client against the real Z-objects.
3. Week 3: put purpose tags and packet logging on the connector. Run a deny-outbound soak if the PSU asked for isolation. Capture the pcap.
4. Week 4: tabletop a posting attempt and a vendor-master change. If either succeeds without a named dialog user, you are not ready for a production purpose.

How this shows up in the file

Subject: Agent access to the SAP estate — connectors and purpose tags only.

The agent will use named existing interfaces (list SID, client, type). It will not be given a new undocumented API in this phase. The service user is retrieval-only. Postings, master-data changes and transport remain with named dialog users under the SoD matrix.

Every call carries a purpose tag. Payloads that identify a person or payment-adjacent data stay inside the company's inference perimeter. The AMS partner is on the RACI for role, transport and hypercare. This note is not SAP or legal advice.

This article is informational field guidance for Indian public sector undertakings and their vendors, not legal, audit, labour, energy-regulatory, banking-regulatory or procurement advice. Confirm the live circular, DPE guideline, CVC instruction, sector regulator text, purchase manual and your counsel before you file it.