Every technology a company adopts arrives as another system with its own data, its own login and its own idea of who the customer is. AI tools need current records to be of any use, connected devices produce a constant stream of readings, and each department signs up for its own SaaS product. If none of it is connected, each addition creates a silo where it was meant to remove one, and the integration work that was deferred last year becomes more expensive with every purchase.
Each new tool arrives as a system
It helps to look at the three categories separately, because each changes the integration problem in a different way.
AI tools produce output: a lead score, a ticket summary, a recommended next action. That output is useful only when it reaches the CRM, ERP or support desk where people already work, and the tool is only as good as the data it can read. A summariser pointed at a ticket queue where half the tickets are in Hinglish and the rest are screenshots will produce summaries of exactly that quality.
Connected devices send sensor readings from machines, vehicles or products. The readings arrive continuously and in volume, and they are of little value until monitoring and operations systems can act on them. The difficulty is less about connecting the device than about deciding which small part of its output any business system should ever see.
Cloud and SaaS applications appear in marketing, HR, finance and operations, each one useful on its own. Together they spread customer and employee data across a dozen places, and nobody has decided which of them owns what. The question is not whether to use them but which system owns each record they touch.
Why overnight batches stop being enough
For a long time, most integration was a nightly export. That was adequate when the people using the data worked on yesterday's figures anyway. It is no longer adequate for interactions where the answer is needed while the customer is still present. A fraud check on a UPI payment, current stock before a dealer confirms an order, a delivery status while the customer is on the phone; none of these can wait for a batch.
The architectural consequence is a mix of two styles. Systems that ask questions need APIs they can call. Systems that must be told when something happens need events they can subscribe to. Most companies will run both, alongside batch jobs for work that can wait, such as the month-end finance pack. The skill lies in assigning each flow to the right style, which our piece on iPaaS, event-driven design and AI in integration works through flow by flow.
Giving a device stream its own path
Consider a fleet operator that puts temperature sensors in its cold-chain trucks. Each truck sends a reading every few seconds. If every raw reading went into the ERP and the support tool, both would be flooded and nobody could find the one reading that mattered. The stream needs a path of its own, with a clear boundary where raw data stops and business events begin.
- DevicesVehicle sensors send readings
- Ingest brokerAbsorbs bursts, keeps order
- Stream rulesFilter, aggregate, raise alerts
- Business systemsERP, maintenance, customer support
Only alerts and summaries cross into the business systems; raw readings stay in the stream and its storage.
With this arrangement, a maintenance team can receive an alert about one specific truck, and support can show a customer the current status of a delivery, without either system storing raw sensor data. The stream rules layer is where the boundary is enforced, and it deserves an owner as clearly as any application does. When a rule changes, for example the temperature threshold for a particular product, someone has to approve it and someone has to be told.
Model output is data with an owner
Output from a model, whether a score, a classification or a summary, has the same integration needs as any other data. It needs a destination system, an owner who is accountable for it, and a way to correct it when it is wrong. Treating it as a side feature of the AI tool, visible only inside that tool's dashboard, is how a useful score ends up ignored.
Where the output feeds a decision, the requirements go further. Take a microfinance lender that uses a model to flag applications for closer review. Someone will later ask why a particular application was flagged, so the integration must record what the model saw when it produced its output: the input fields, their values at that moment and the model version. That record belongs in a system the lender controls, outside the vendor's tool.
AI-assisted integration tooling, such as suggested field mappings and anomaly detection on data flows, can reduce setup effort. Its suggestions still need review by someone who knows the data, because a plausible but wrong mapping writes bad records quietly. The options for building AI features into business systems are described on our AI solutions page; the integration questions are the same whichever option is chosen.
Where adoption goes wrong
The most frequent error is connecting an AI pilot to a manual export. It works for the demonstration and cannot be kept current, so the pilot stalls within a few months and the model takes the blame for what was a data problem. Next is sending raw device data into business systems without filtering it first, which buries the signal and slows the systems down.
Alerts raised with no named recipient are a third pattern, and they are common in device projects. Departments adopting SaaS tools without a record of what data each one holds is a fourth; the IT head learns about the new HR tool when it asks for employee bank details for payroll. Underneath all of these is the habit of treating integration as a project that ends. Every new application reopens it, and a company that plans for that spends less than one that is surprised by it each time.
Questions for the next tool purchase
- Data needs found during rollout
- Output copied by hand
- A new silo within a quarter
- Data sources and owners named
- Output has a destination system
- Failures have a recipient
The same tool, with the connection decided before or after purchase.
Integration planning belongs in the buying decision, before the contract is signed. For the next tool your company evaluates, the buyer should be able to answer three questions in writing. Which system owns the data the tool needs, and does the tool offer an API or event feed in the plan being purchased? Where does its output go, and who acts on it? How will anyone notice when it stops sending or receiving?
Add those questions to your evaluation template this week. Our enterprise application integration work starts with the same list. A company that asks them for every purchase keeps a short, known list of systems that own its data; one that does not will, within a few years, own a dozen tools that each hold a slightly different version of its customers.
