Your Guide on How to Prepare Your Company's Systems for AI

The push to put AI into your business right now rarely gets specific about what that touches.

It touches the CRM your team has patched for twelve years. The claims system that’s never been fully documented since the person who built it left. The ERP running your plants, which has three names for the same product depending who you ask.

Examples of where this can get dangerous:

• Finance: one transaction can touch four or five systems, each holding a piece of regulated data. Handing AI broad access before anyone’s checked how those systems disagree creates a liability with your name on it later.
• Healthcare: a patient’s real record is split across the EHR, the pharmacy system, sometimes a scheduling tool that’s never talked to either, kept straight for years by a nurse who holds all of it in her head.

We’ve built AI directly into processes running on top of exactly this kind of mess, in both, without tearing out what already works. Ripping out a system that’s run a business for fifteen years, just to make room for AI, is almost always the wrong call, and an expensive way to learn that.

This is the second piece in a three-part series. Read about how to prepare your company’s data for AI here. This one covers your systems, whatAI’s allowed to touch. The third, coming next, will cover your people, who answer for what it decides.

Stage 0: Pick one system to start with

Pick the process with the most manual reconciliation happening right now, that’s where a person is already absorbing the most disagreement by hand. Then weigh how cheap it is to get wrong while you’re still learning. Start there.

Stage 1: Find out where your systems already disagree

A customer is an account number in the CRM, a billing reference in the ERP. No one mapped the two, because a person doing the lookup by hand never needed to.

Do this:

• Pull one real record for the same customer, order, or case from each system, side by side.
• Find the field that already ties them together, an email, a phone number, even if the ID numbers don’t match.
• Take ten real, current cases and ask both systems the same question, is this deal open, is this order shipped.
• Check which system was correct, for each of the ten. One system right eight or nine times out of ten, write that down as the standing rule. Closer to a coin flip, the real rule depends on something else, who touched it last, which date, document that instead.

Stage 2: Confirm the system has a real action to call, not just a screen

A screen built for a person to click needs a person clicking it. A machine needs a real function to call instead.

Do this:

• Ask directly: can this system take the action through a real function call, or does someone have to click through screens?
• Honest answer is clicking? Don’t build an AI agent or workstream that fakes the click, it breaks the first time the screen changes.
• Real action exists? Confirm it does exactly your task. A “delete” action and an “archive” action can look identical from outside and mean something very different underneath.

Stage 3: Test the agent against real cases before it goes live

Do this:

• Pull 20 to 30 real cases from the last few months.
• Run each one through the proposed agent and compare it to what a person did.
• Every place they disagree is either a bug or an undocumented exception, find out which before you decide it’s ready.
• Same trigger shows up three or more times? Write it down as its own rule, it’s earned one.

This is precisely what we do before AI gets near a live system: find which system wins the disagreement, prove it against real cases, and shadow-test every action before it’s allowed to touch anything for real. Let’s talk and we’ll walk your systems through this exact exercise.

Stage 4: Expand theAI’s access only after the stages above hold

Do this:

• Read-only access first. Confirm its answers match what a person would say, every time, before any write action.
• One scoped write action next, the one already tested in stage three.
• Broader execution only once an exception has been caught without a human catching it first.

Stage 5: Recheck the map and the rule as your systems change

The translation map and the authority rule both go stale the moment someone renames a field or swaps a vendor, the same way a document goes stale in piece one.

Do this:

• Name one person as owner for the translation map and the authority rule.
• Tie the recheck to something that already happens, a system upgrade, a vendor migration, a schema change, something harder to skip than a calendar reminder.

Stage 0: Pick one system to start with

Stage 1: Find where your systems disagree

Stage 2: Confirm there’s a real action to call

Stage 3: Test against real cases first

Stage 4: Expand once earlier stages hold

Stage 5: Recheck as your systems change

The path for getting your systems ready for AI.

This is precisely what we do: find where your systems disagree before AI finds out the hard way, test every action against real cases before it goes live, and keep the rules checked as your systems change under them. If that’s where your company is right now, let’s talk.

Next in this series: the people who have to answer for what the agent decided.