Your Business Isn’t AI-Ready Yet: What I’d Fix Before Building AI Agents

Your ERP says one thing. The finance spreadsheet says another. The employee who understands the difference is retiring next year.

Imagine asking an AI agent which overdue invoices to chase first. It can answer confidently while missing disputed invoices, mismatched customer identifiers and last month's policy change.

In that situation, my first question would be: where does your business truth actually live?

An AI readiness assessment should establish whether one valuable workflow has trustworthy inputs, enforceable permissions, usable integrations and a way to judge the result. Start there before funding the agent.

AI adoption is moving faster than data readiness

Dun & Bradstreet's India AI Momentum Survey release, August 4, 2026, reports that 69% of surveyed Indian businesses plan to increase AI investment and 73% report some measurable return. Only 4% say their enterprise data is fully ready to support AI at scale.

Its July 28 global release puts full readiness at 6%. The global survey covers 10,000 businesses across 32 countries; the India release does not specify its local sample size. These are self-reported assessments, not independent audits.

My takeaway: a successful pilot does not establish that the approach can cross departments safely.

Salesforce's September 11 Enterprise AI Harness announcement likewise separates context, agency, action, governance, security and models. It is a vendor's proposed architecture, but the principle is useful: business AI needs controlled access and execution around the model.

Start with one workflow and its sources of truth

I would trace a collections review with the people doing it: source records, spreadsheet adjustments, current policy and approval history.

“Finance owns the data” is too vague. Who defines overdue? Does the calculation use contractual due dates or negotiated extensions? Which system records disputes?

Create a small authority map: each business concept, its source of record, owner, freshness requirement and conflict-resolution rule. Different facts can have different authoritative systems. You do not need to move everything into one database.

The diagram shows dependencies. Identity applies throughout, and every proposed action must return through authorization checks and application business rules before changing a record.

Readiness 1: Data you can reconcile

Start with identifiers and meaning. Does the CRM customer match the legal entity on the invoice? Check currency, units, duplicates, missing values and the difference between an empty field and zero.

Inspect the spreadsheet too. It may contain legitimate corrections that never reached the application. Reconcile a sample of invoices across systems with a finance owner. Every mismatch needs an explanation or an assigned fix.

Record how old each source can become before its answers stop being useful. Yesterday's export may support a weekly review but fail a real-time credit decision.

Ask for: reconciled records, stable identifiers, freshness limits and named owners. A successful export alone does not establish data readiness.

Readiness 2: Integration through controlled boundaries

Can the API return records this user may access? What happens after a timeout, duplicate request or partial failure?

A collections assistant might initially need only read-only invoice status. Sending reminders requires validation, approvals, duplicate protection, audit history and recovery.

Keep transactions and business rules in the existing application. My Add AI to an Existing Application approach uses those boundaries instead of duplicating the business inside an agent.

MCP can standardize tool access. It cannot reconcile customer identifiers or choose the correct revenue definition. Connectivity does not establish trustworthiness.

Ask for: one narrow operation demonstrated end to end, including failure and retry. Scheduled exports can support a useful read-only workflow if their freshness limits are explicit.

Readiness 3: Permissions that survive retrieval

Ask what this person may see and what they may cause the system to do.

Access to a customer record does not necessarily permit access to credit notes or another region's contracts. Search indexes, snippets, citations, caches and logs must preserve the appropriate restrictions.

Test allowed and denied requests across roles, including recently revoked access. The application must enforce authorization independently of the model. A confidentiality instruction in a prompt cannot do that job.

For actions, distinguish the initiating user from the integration account. Its privileges must not silently become every user's privileges.

Ask for: access tests and an audit trail connecting user, request and outcome. Missing enforcement blocks access to restricted data, whatever the overall readiness score.

Readiness 4: Knowledge with sources and owners

Important dependencies live outside databases: a policy in a PDF, a meeting decision or the reason a spreadsheet overrides the ERP.

Gather the relevant knowledge for this workflow. Identify approved versions, owners, effective dates and superseded guidance. A business owner must resolve contradictory policies; retrieval can only expose the disagreement.

I build Context Harbor around private, source-backed project knowledge. Its integrations expose project-scoped knowledge through MCP, REST and the Web UI. That illustrates the context layer. The business still needs accountable owners, consistent records and correctly configured access.

Ask for: representative questions answered from current, identifiable sources, with an explicit “we do not know” when evidence is missing.

Readiness 5: Separate rules from judgment

Application code should calculate overdue days, enforce account ownership and check approval requirements. AI can summarize a dispute or draft a reminder for review. It should not invent payment terms.

Start with a proposal-and-review flow. Show the reviewer the action, source records and relevant policy. Bind approval to that action, then recheck state and permissions before execution. A newly disputed invoice should stop a previously approved reminder.

Ask for: decision owners, exception routes, action limits and a stop mechanism. Reviewers need enough evidence and time to catch mistakes; an approval button alone does not establish control.

Readiness 6: Evaluate business outcomes

Have the workflow owner define acceptable results before building. Collect ordinary cases alongside missing records, conflicting policies, stale data, unauthorized requests and attempts to override the assistant's instructions.

Check whether amounts match sources, citations support explanations and restricted information stays inaccessible. For actions, test duplicate execution and recovery.

Then measure preparation time saved after review, correction effort and operating cost. An answer that takes longer to verify than the existing process has not earned its place.

Ask for: an evaluation set, release criteria and someone who can pause the feature. Choose thresholds according to the consequences of mistakes; no single accuracy percentage makes every workflow ready.

My 15-minute AI readiness scorecard

Use this with a business owner and technical owner. It is a triage framework, not a validated maturity model or deployment approval.

Spend three minutes selecting one workflow and measurable improvement, nine minutes rating the dimensions, and three minutes assigning the biggest gaps to owners.

Score each dimension 0 for missing or unknown, 1 for partial coverage or manual checks, and 2 for demonstrated evidence in this workflow. Do not award a 2 on verbal assurance alone.

Use the total out of 12 to prioritize investigation:

• 0–4: establish foundations. Map sources, reconcile records and assign process ownership.
• 5–8: consider a bounded assistant. Close relevant gaps, then evaluate read-only answers or reviewed drafts.
• 9–12: investigate controlled actions. Prove permissions, approvals, retries and recovery before allowing writes.

Blocking conditions override the score. Missing identity controls block restricted data access. Missing process controls block writes. Missing evaluation blocks production release. Unresolved conflicts in critical sources block relying on the answer.

A team scoring 2 everywhere except identity still totals 10. I would keep its pilot on approved non-sensitive test data until access enforcement works.

What I would build next

At the foundation stage, the deliverable could be customer-ID mapping, a cleaned invoice feed and an agreed dispute policy. Those improvements can help operations before AI ships.

With trustworthy read access, I would consider a collections briefing assistant with source links. Staff would continue acting through the existing application.

With proven action controls and evaluation, I would consider drafting reminders and sending approved messages through the existing service. Keep a manual fallback and measure actual time saved before expanding.

The assessment should produce a decision: build a bounded AI use case, fix a specific foundation first, or choose conventional automation. Finish with a prioritized backlog, owners and acceptance evidence, not another platform shopping list.

Make the business AI-addressable first

Your entire company does not need perfect data. Your selected workflow needs the right facts, appropriate access, controlled operations and evidence that the result helps.

That is where I would start an AI application and agent development engagement. If the obstacles sit deeper, architecture and modernization support can define the necessary changes.

Considering AI for an existing process? I can help map where your data, business rules, permissions and knowledge live, then identify the smallest useful AI implementation.

Assess My AI Readiness