Security and data handling

Where the model runs

Four options, chosen by your data policy. Amazon Bedrock in the Frankfurt region or Google Vertex AI in an EU region, both under your own cloud account, so the contract with the provider, the retention settings and the invocation logs are yours; support access and abuse monitoring follow that provider's terms. Or Claude Enterprise: the Claude apps and their MCP connectors run in Anthropic's infrastructure, and where prompts, files and tool results are processed and retained is set by Anthropic's enterprise terms and your administrators' settings. Or OpenAI: ChatGPT Enterprise with data residency in the EU or the US under OpenAI's business terms, or the OpenAI models on Amazon Bedrock under your own AWS account with EU routing. Retention, logging, cross-region inference and training terms differ by provider, region, model and endpoint. The data-handling map that states them per component is part of the assessment, before you decide, and is updated before go-live; you keep it.

We operate no service that your data passes through: the AI layer runs in your environment, and the people on the engagement see your data only inside your systems, through accounts your administrators grant and revoke. Engagement documents that contain your data live in your tenant.

Identity and access

• People sign in through the accounts they already have, Microsoft Entra ID or Google Workspace, with your conditional access and MFA policies in force.
• Each tool the AI layer can call is on an allowlist per role, checked on the server for every call; a client that asks for a tool outside its role is refused, whatever it shows on screen.
• Systems of record are reached through scoped technical accounts with only the roles the use case needs. For SAP this means the person's own SAP roles and segregation-of-duties rules do not apply inside the pilot, so the account is limited to data every pilot user may see, and your SAP security team verifies that scope before the pilot starts. Propagation of the person's own identity is on the roadmap and is stated as a limit in every proposal.
• Our own access during an engagement is personal, time-limited and logged in your systems, and it ends with the engagement.

Data minimisation and masking

• Personal identifiers are replaced in the layer before a request leaves your network: identification numbers, IBANs, e-mail addresses, phone numbers and names in structured fields, with a reversible token so the answer can be mapped back inside your network.
• Free text, material and vendor descriptions, attachments and custom fields are not covered by the default masks. Each pilot process gets its own data review, and a process whose data cannot be masked well enough stays out of the pilot.
• Tables with credentials, secrets or personal data are refused by default in the SAP server. The denylist is a guard, not a classification; a pilot classifies the tables it reads.
• The layer keeps no copy of your data beyond the audit log and the caches your administrators configure.

Audit

Every call writes one JSON line: time in UTC, the signed-in person, the technical account, the tool, the arguments, the status, the duration and a note. In production the lines are forwarded to your log store or SIEM; the local file is a record, not a control, and your retention policy applies. The audit log contains every query, so it is treated as sensitive data in your environment. Your auditor reads the same lines we do.

Writes and approvals

• The published SAP server is read-only. A write exists only for a BAPI on an allowlist, only inside a pilot, after your IT team has approved it.
• Every write runs after a named person confirms the proposal in the client, and the confirmation is in the audit line. That confirmation is not an SAP workflow approval or an electronic signature; writes that need one stay out of the pilot.
• Writes that create documents in SAP are listed per document type, because SAP's Digital Access licensing applies to them.

Secrets, network and transport

• Credentials live in your vault, for example Azure Key Vault or AWS Secrets Manager, and are read at runtime. No production password sits in a configuration file.
• The AI layer runs inside your network. Outbound traffic goes to the model endpoint and nowhere else; the list of endpoints is in the data-handling map.
• RFC traffic to SAP is protected with SNC and HTTP traffic with TLS. Which RFC implementation supports your SNC setup is decided with your Basis team; the open-source bridge uses an implementation SAP does not support, and it gets its own review before a pilot.
• A pinned release with its dependency list and a threat model are delivered with the pilot, so your security team reviews a fixed artefact, not a moving repository.

Subprocessors and contracts

Which subprocessors are involved depends on the deployment you choose: Amazon Web Services, Google Cloud or Anthropic for the model, under your own contract with them in the Bedrock and Vertex AI options. We sign a data processing agreement for the engagement, name the people with access and accept your security policies in the contract. The data processing agreement published for the Autopilot product is a separate document and does not cover consulting engagements.

What we do not have

• No ISO 27001 or SOC 2 certificate. We answer security questionnaires with the practices on this page and accept audits of the deployment in your environment.
• No production SAP ECC reference yet. The first ECC pilot is in preparation for the fourth quarter of 2026.
• No bug bounty programme. Security findings in the open-source server go to info@iteractive.ai.

What we ask from you

• A named security contact and a named SAP Basis contact for the interface and role questions.
• A sandbox or a non-production client with representative data for the first weeks, and the vault and log store endpoints the layer should use.
• Your security policies and the data processing agreement you want signed, so they go into the contract as written.
• Thirty minutes with your security team during the assessment. We bring the data-handling map and the list of interfaces, and we leave with your objections in writing.

Incidents and exit

• A security incident in a deployment is reported to your named contact without undue delay, with the facts we have, and we support your notification duties under the GDPR.
• A documented exit is part of every deployment: how the layer is stopped, the technical accounts revoked, the configuration exported and the process returned to manual operation.

Questions we get asked

Is our data used to train models?

Not in any of the options as we configure them. Amazon Bedrock and Google Vertex AI do not use customer inputs to train their models, Claude Enterprise excludes training under its enterprise terms, and ChatGPT Enterprise and the OpenAI API do not train on business data by default. The exact terms per component are in the data-handling map.

Where is our data processed?

In the region of the endpoint you choose: Frankfurt or a US region on Amazon Bedrock, an EU or US region on Google Vertex AI, the residency you select in ChatGPT Enterprise. Claude Enterprise processes requests in Anthropic's infrastructure under its enterprise terms. Whether cross-region inference is on is a setting we document.

Who at iteractive.ai can see our data?

The named people on the engagement, through accounts your administrators grant, for the time of the engagement. We do not copy your data to our systems.

Can we audit the deployment?

Yes. The code of the SAP server is public, the configuration is yours, the audit log is in your log store, and we support an audit of the deployment in your environment.

Do you hold a security certificate?

No ISO 27001 or SOC 2. The cloud providers in the Bedrock and Vertex AI options hold their own certifications; our practices are the ones on this page.

How do we report a vulnerability?

By e-mail to info@iteractive.ai, with the component and the steps to reproduce. Findings in the open-source server are fixed in the public repository.

Send us your security questionnaire

We answer it with the practices on this page and the data-handling map of the deployment you are considering. A 30-minute call with your security team is part of every assessment.

Book a 30-minute consultation

Or write to us directly: info@iteractive.ai · +421 905 452 325