An AI application can only support your business processes if it can reach your data and functions through an API. That takes five things from your systems: readable APIs, write access with clear limits, events, current data, and permissions per user. When a system has no usable API, you build that access first and add the AI afterwards.
Most organizations that start with AI have a concrete goal. An employee wants to ask about an order in plain language, a planner wants a proposal for tomorrow's schedule, an account manager wants a draft quote based on the customer's history. The language model is the easy part. The real work sits in the ERP, the CRM, the planning software, and the custom application where that data lives.
This article covers what an AI application needs from your APIs, how to assess your application landscape, what to do with systems that have no API, and where the Model Context Protocol fits. After more than 30 years of building integrations, we see AI as a new consumer of the same APIs.
Why AI starts with the API
A language model knows nothing about your orders, stock, or customers. It only knows what an application hands it at the moment of the question, and it can only act through functions that an application exposes. That makes every AI application a consumer of your systems, just like a customer portal or an API integration with a supplier.
For many organizations, that's where things get stuck. The MuleSoft 2026 Connectivity Benchmark Report counts an average of 957 applications per organization, with only 27% of them integrated. The survey covered 1,050 IT leaders in nine countries, including the Netherlands, in late 2025. Of those leaders, 96% say AI agent success depends on data integration across all systems, and 94% expect their IT architecture will have to become more API driven.
Developers see the same picture. In Postman's 2025 State of the API Report, based on more than 5,700 developers, architects, and executives, 24% already design their APIs with AI agents in mind. Most teams still build for human users and known integration partners.
What an AI application needs from your systems
An AI application asks the same of your systems as any other consumer, only more strictly. It reads documentation literally, calls functions more often than a person would, and has no built in sense of what it should leave alone. These five properties decide whether a system is usable.
- Readable APIs. Endpoints that return data in a fixed structure, with a description for every field. A field called "status2" with no explanation turns into guesswork for an AI application.
- Scoped write access. A separate, narrow function for each action: create a draft quote, propose an appointment, add a note. General write access to tables has no place here.
- Events. A notification as soon as something changes, such as a new order or a delayed delivery, through webhooks or a message queue. The application then doesn't need to keep asking whether anything has changed.
- Current data. An answer based on last night's stock levels is useless to a planner. Nightly exports work for reporting, but AI that supports daily operations needs data from this moment.
- Permissions per user. The AI application sees what the employee asking the question is allowed to see, and nothing more. That only works when the API knows on whose behalf a request comes in.
The last point gets too little attention. In the same Postman survey, 51% name unauthorized or excessive API calls by AI agents as a concern, and 49% worry about AI systems accessing sensitive data they shouldn't see. Both risks shrink when the API itself enforces permissions, instead of relying on an AI application to be careful.
How to assess your application landscape for AI
Start with the processes where AI should help and work back to the systems involved. Two or three processes give you a usable picture faster than the whole landscape at once. Ask these questions for each system.
| Question | What to look for |
|---|---|
| Is there an API? | Documented, versioned, and available under your license |
| What can you read? | Which objects and fields, with which filters and search options |
| What can you write? | Individual actions, validated by the system itself |
| How current is the data? | Straight from the source or through a delayed copy |
| On whose behalf does it act? | One generic service account or the permissions of the signed in user |
| Does it report changes? | Webhooks, messages, or only periodic polling |
Documentation is often the weak spot. Among Postman's respondents, 55% struggle with documentation that is inconsistent, outdated, or missing. A description based on the OpenAPI Specification helps right away. It records endpoints, fields, and error responses in a format that developers can read and that tools can turn into functions for an AI application.
After the assessment, each system falls into one of three groups:
- Ready. A documented API with read and write functions, permissions per user, and current data.
- Usable with changes. An API exists, but functions, documentation, or a link to the user's permissions are missing.
- No usable access. Data can only be reached through the screen, an export, or directly in the database.
What to do with systems that have no API
Older custom systems and closed software packages usually end up in the third group. There are three routes, from light to substantial.
- Build an API on the system itself. For your own application, this is usually the cleanest route. Business rules stay in the application and the API makes them reachable. That's the work of API development: design, security, documentation, and versioning.
- Add an integration layer next to it. When you can't change the system itself, a separate layer offers a clean API. It reads from a restricted database view or from files and writes through the system's existing input routes. A layer like this falls under software integration and serves other consumers as well.
- Modernize. When the logic sits in a system nobody fully understands anymore, an API is only a patch. Targeted legacy modernization of the part AI needs makes the system usable for the next integration too.
We advise against two routes. Never let an AI application write directly to the database, because that bypasses every check the system itself performs. Screen automation is a stopgap: it breaks with every change to the interface and makes permissions per user hard to trace.
Where the Model Context Protocol fits
The Model Context Protocol (MCP) is an open standard for connecting AI applications to external systems. Anthropic introduced MCP in late 2024. Since 9 December 2025 it has been part of the Agentic AI Foundation at the Linux Foundation, cofounded by Anthropic, Block, and OpenAI. At the time of that move, more than 10,000 MCP servers had been published.
The specification, whose latest version is dated 28 July 2026, describes three building blocks an MCP server can offer:
- Resources: context and data for the user or the AI model to use.
- Prompts: templated messages and workflows for users.
- Tools: functions for the AI model to execute.
For your application landscape, this means an MCP server is a thin layer on top of your existing APIs. That layer translates your API into tools and resources that any AI application with MCP support can discover and call. Without a good API underneath, an MCP server has nothing to offer. The order is always the same: API first, MCP layer second.
The permissions question comes back in that layer too. For connections over HTTP, MCP authorization builds on OAuth 2.1, with scopes per operation and tokens that are only valid for the server they were issued for. An API that already knows about permissions per user connects to this without detours.
AI works best when people stay close to it
Our view is a practical one: AI works best when people stay close to it. When we build APIs for AI, that translates into a few fixed choices.
- Start with reading. An AI application that looks up and summarizes data delivers value quickly with little risk.
- Turn write actions into proposals. The application prepares a draft and an employee confirms it.
- Log every call, including the user on whose behalf it was made.
- Keep functions small, so you can decide per action who may use it.
The MCP specification points in the same direction. Its first key principle reads:
"Users must explicitly consent to and understand all data access and operations." (Model Context Protocol specification)
Isatis has been building integrations and APIs for more than 30 years, from maintenance software for aviation to a subsidy administration platform and RFID in the supply chain. With 30+ engineers in Nijmegen and Sarajevo, more than 100 projects, and ISO 9001 and ISO 27001 certification, we know how to open up a system without losing control over it. Our data and AI page explains how we approach this. Book a conversation if you'd like to know which systems in your landscape are ready for AI, and we'll go through the assessment with you.
Frequently asked questions
What is an API for AI?
An API for AI is a programming interface that an AI application uses to read data or carry out actions in a business system. Technically, it's a regular API. The difference is in the requirements: clear descriptions per field, narrow functions per action, current data, and permissions that apply per user.
Does my ERP or CRM need an API to work with AI?
Yes, as soon as the AI application has to work with current data or record something in the system. Many standard packages offer an API. Check what that API can read and write under your license, and whether it respects the permissions of the signed in user.
Does the Model Context Protocol replace my APIs?
MCP works on top of existing APIs. An MCP server translates your API into tools and resources that AI applications can discover and call. Without a usable API underneath the MCP server, there is nothing to offer.
Where do you start if your systems have no API?
Start with one process where AI genuinely helps and identify the systems it depends on. For each system, choose between an API on the system itself, an integration layer next to it, or targeted modernization. Writing directly to the database is not a good route.
