Why does disconnected data limit what AI can do?

A business may have customer details in its CRM, invoices in finance, contracts in document storage and delivery updates in another application. People become the connection between them: looking up names, checking versions, copying figures and explaining exceptions. Adding an AI tool does not automatically resolve those mismatches.

Kevin describes the value of gathering and transforming data into a reusable form. At CSM, the commercial question comes first: which decision or piece of work becomes easier when the right information is available together? That question prevents a data project becoming a large collection exercise with no agreed use.

Does everything have to move into one central database?

No. A shared data foundation is an architectural choice, not a requirement to replace every operational system. Some records can be copied into a reporting store, some documents can remain in their existing repository, and some information can be fetched through an authorised connection when needed. The design depends on freshness, access, volume and the work being supported.

For an initial implementation, we would usually define a bounded set of required information. The CRM might remain authoritative for account ownership while the finance system remains authoritative for invoices. A connected view should make those responsibilities clearer. It should not create a competing set of manually maintained facts.

What do APIs, ETL and ELT actually mean for a business leader?

An API is a defined way for software systems to exchange requests and data. A working connection proves that information can move; it does not prove the meaning, completeness or accuracy of that information. You still need to establish which records to request, how often and what to do when access fails.

ETL means extracting data, transforming it and loading it into a destination. ELT loads it before transforming it in the destination. Transformations can include joining records, normalising formats, removing duplicates and validating fields. Microsoft’s architecture guide explains the distinction. Leaders do not need to select the acronym first; they need to specify the required result and controls.

What must the business agree before connecting the tools?

Start with ownership and definitions. Who can confirm that a customer record is correct? Does “revenue” mean invoiced, recognised or collected revenue? Does “active customer” have the same meaning in sales and finance? If two teams use different definitions, the system should expose and resolve that distinction rather than hide it behind a dashboard.

Agree shared identifiers as well. Matching on a company name alone can join the wrong entities or miss duplicates. Subsidiaries, trading names and merged accounts need explicit treatment. Keep a record of how source identifiers map to the shared view and a route for reviewing uncertain matches. An AI guess should not silently become an authoritative link.

What would a useful first workflow look like?

Consider an illustrative account-review workflow. A manager needs the current contract, open invoices and unresolved service issues before a renewal discussion. Today, three people gather the information. The first release could join the approved account identifiers, fetch those records and assemble a dated evidence pack with links back to the sources.

Controlled software calculates overdue balances from finance records. AI may summarise the service history, clearly distinguishing open issues from resolved ones. The account manager checks the evidence and decides what to say to the customer. The system prepares the review; it does not invent a commercial commitment or treat a draft contract as the signed agreement.

This creates a specific test of value: is the review faster to prepare, are fewer records missed and are discrepancies visible earlier? It also makes the data scope manageable. You do not need every historic file or every department’s data to answer those questions.

How do you know whether the connected data is good enough?

Define quality in relation to the workflow. Required fields should be present; identifiers should match; dates and currencies should be consistent; duplicate events should not produce duplicate actions. Reconcile key totals against the source. A successful connection and a plausible dashboard are not substitutes for these checks.

Set a freshness requirement. A daily update may be sufficient for a planning report but unsuitable for a workflow that relies on a recently changed account restriction. Display the last successful refresh and stop or flag dependent work when the data becomes too old. Assign an owner to investigate failures instead of leaving users to discover stale information by accident.

Keep provenance: where the record came from, when it was fetched and what transformation was applied. This helps someone explain a disputed figure and trace an error back to its source. NIST’s AI RMF core emphasises documented evaluation and ongoing monitoring; the underlying data pipeline needs that same operational attention.

Who should be able to see the information?

A central view must not mean universal access. Define permitted uses and access by role, client or other relevant boundary. The same restrictions need to hold when AI retrieves information. A service account’s ability to read a source does not automatically mean every end user should see everything it reads.

Include retention, deletion, access revocation and recovery in the design. Where personal data is involved, determine the lawful purpose and applicable obligations with the responsible privacy team. A Data Protection Impact Assessment is required for processing likely to result in high risk to individuals; assess that requirement rather than assuming a technical integration is only an IT matter.

When is custom code justified?

Use an existing, supported connector or platform feature when it meets the requirement. Custom code may be useful for unusual mappings, validation, orchestration or business rules that packaged tools cannot express adequately. It also creates a maintenance obligation: tests, documentation, monitoring and someone able to update it when a source changes.

Our recommendation is to fund a dependable workflow, including its upkeep. Agree the business owner, source owners, technical support and acceptance checks before treating the connection as complete. The value comes from reliable information used in the work, not the number of applications connected.

What should I read next?

Explore how to make a chatbot trustworthy and which workflows are worth automating.