Systems Place Insights

Read-only AI access to ERP and CRM data: questions to ask before launch

Sun, 19 Jul 2026 11:50:28 GMT

Read-only is a useful starting policy for AI access to ERP and CRM data, but it is not a complete security description. Before launch, make the identity path, source permissions, assistant and provider boundaries, logs, operating responsibilities and separately approved write path explicit.

Define what read-only means in the implementation

A read-only service should expose only operations that retrieve approved data. It should not create, update, delete, approve or submit records. Check this at the connected-tool layer and at the source-system account, so a prompt or configuration mistake cannot turn a read into a write.

List the allowed operations and the data each one can return. Broad database or API access is not a substitute for a clear service boundary.

Give every user an explicit identity path

Decide whether the source sees the individual user, a service identity or both. Record how the assistant session maps to that identity, how access is granted and revoked, and who reviews it. Shared credentials make individual approval and investigation harder and should not be the default.

Which people and roles may use the connection?
How are they authenticated at the assistant, connection and source?
Which source roles, companies, territories, fields and periods may each user see?
How quickly does a role change or departure remove access?
Who owns periodic access review?

Enforce permissions close to the source

Use the minimum source permissions needed for the approved questions. Preserve source-system controls where practical, and apply any additional filtering in a layer with a named owner and test coverage. Do not rely on prompt instructions to hide restricted records or fields.

Test users who should receive different answers as well as users who should be denied. Include fields that are sensitive even when the surrounding record is allowed.

Trace the complete data path

Document where a request starts, which connection and tools handle it, which systems receive it and where prompts, results, logs or caches may be retained. Include the selected AI assistant plan, provider settings, hosting location and any subprocessors or gateways that are part of the agreed route.

Assistant and connector features vary by provider, plan, workspace settings and deployment method. Verify the current combination for the customer rather than treating general product availability as proof of compatibility. The AI Assistant Compatibility reference explains the checks to make.

Decide what is logged and who responds

Useful operating evidence can include authentication events, tool calls, source outcomes, rejected requests and service failures. Record who can read those logs, how long they are retained and who investigates an incident. Avoid logging more business data than the operating purpose requires.

Define the response path for suspected exposure, compromised credentials, an unavailable source and an answer that does not match a trusted result. Include customer and service-provider responsibilities.

Check answers as well as controls

Security controls do not establish that an answer uses the right business definition. Test representative questions against reports, calculations or known results the business already trusts. Also test denied access, missing data and unsupported questions. These checks form part of the acceptance decision before launch.

Treat every write as a separate approval

If a later use case needs to create or change a business record, do not expand the read-only connection silently. Review the action, preconditions, permissions, approval, failure handling and evidence separately. The Operational Decision System is the service path for controlled system actions when analysis is not enough.

Use a launch checklist with named owners

The approved business question, users, sources and data are documented.
The connected tools and source account cannot write.
Allowed and rejected access paths have been tested.
The assistant plan, provider processing and retention choices are recorded.
Representative answers have been checked against trusted results.
Monitoring, incident contacts, change handling and exit steps have owners.

See the full Security and Data Handling approach, or start with an AI Analytics Assessment to review one question, its data path and the simplest suitable route before any build.

How to check AI answers against the business reports you already trust

Sun, 19 Jul 2026 11:50:28 GMT

An AI answer should be checked against a report, calculation or known result the business already trusts before it becomes part of recurring work. The aim is not to prove that every answer will always be correct. It is to define what a good answer looks like, test representative conditions and make limits visible.

Turn the business question into a testable case

Begin with the exact question and the decision it supports. Record who may ask it, which source records are allowed, which business definitions apply and which existing result will be used for comparison.

The measure, period, currency and organisational scope
The treatment of returns, cancellations, missing records and late changes
The expected level of detail and any fields that must remain unavailable
The report owner or business owner who can explain material differences
The conditions for accepting, revising or stopping the use case

This preparation matters because a fluent answer can still use the wrong definition, period or population. A trusted report provides a concrete reference point, while the documented definitions explain what is being compared.

Use a representative set of questions

A single successful example is not an evaluation. Use a compact set that reflects ordinary work and the conditions most likely to reveal a problem.

Known ordinary cases: questions with stable, approved comparison results
Business edge cases: returns, credit notes, missing targets, inactive customers or period boundaries
Access cases: users who should see different records, fields or levels of detail
Unavailable-source cases: a delayed source, expired authentication or incomplete data
Unsupported questions: requests the service should decline or redirect rather than guess

Reconcile the answer at the right level

Compare totals first, then the records and rules that explain them. A difference may indicate a defect, but it may also reveal a timing change, a filter in the trusted report or an agreed difference in scope. The reviewer should be able to trace the answer to its sources and explain any material variance.

Use exact agreement where the business rule requires it. Where rounding, currency conversion or source timing makes exact agreement inappropriate, define the acceptable treatment in advance. Do not invent a universal tolerance after seeing the result.

Test answer quality and access separately

A numerically correct answer still fails if it exposes data to the wrong user. An access test still fails if the service silently broadens a filter, calls an unapproved operation or returns restricted fields. Test the approved path and the rejected path for each important role.

Also check failure behaviour. When the data is unavailable or the question is outside the agreed scope, the assistant should say so clearly. It should not fill the gap with an unsupported estimate.

Record an acceptance decision

Keep a short evaluation record for each representative case: the question, user role, expected source, expected result, observed result, explanation of any difference and reviewer. The business owner can then accept the use case, request a revision or stop it on evidence rather than impression.

Acceptance applies to the agreed question, systems, users, assistant and environment. A new source, definition, provider setting or use case is a change to review, not automatic proof that the earlier result still holds.

Keep the checks current after launch

In the Run stage, repeat representative checks after material changes and on the agreed review schedule. Monitor authentication, source availability, tool outcomes and relevant failures. Update the evaluation set when the business changes how it defines or uses the answer.

Read-only analysis and system actions are separate decisions. If the service later needs to create or change records, the Operational Decision System adds explicit policy checks, permissions, approval and controlled execution. The original answer checks remain necessary.

The AI Analytics Assessment defines the first evaluation plan before a build. The full Assess, Build, Run process carries that evidence through launch, maintenance, change and exit.

Native ERP AI, BI, a managed platform or custom MCP: how to choose

Sun, 19 Jul 2026 11:50:28 GMT

The right route is the one that answers an agreed business question with approved data, clear definitions and an operating owner. Sometimes that is a feature already available in the ERP or CRM. Sometimes it is BI, a managed platform or a purpose-built MCP connection. Sometimes the right decision is to fix a prerequisite or not build.

Start with the question, not the technology

Define one recurring question, who needs the answer and what decision it supports. Name the systems likely to contain the answer and a report, calculation or known result that the business already trusts. This makes the options comparable on practical grounds.

A route is suitable only when it can apply the agreed business meaning, respect source permissions, return enough evidence to check the answer and be maintained as systems and definitions change.

Compare the smallest useful routes

Native ERP or CRM capability

Start here when the question stays within one source system and its built-in assistant or analytics feature can use the right records, definitions and user permissions. The main checks are data coverage, answer quality, plan availability, provider processing and who will maintain the configuration.

Existing BI

BI is often the simplest route when approved models already combine the required data and business definitions. It can provide a stable comparison layer and preserve familiar access rules. Confirm that the intended assistant can reach it safely and that the model answers the actual question rather than only reproducing a fixed dashboard.

Managed platform

A managed platform can fit when several approved sources need to be brought together and the customer wants one party to own implementation, monitoring, support and controlled change. Review what the platform stores, how identity and permissions are enforced, which assistants it supports and how data and configuration can be handed over or removed at exit.

Purpose-built MCP connection

Model Context Protocol, or MCP, is one way for a compatible AI assistant to call approved tools. It can be useful when existing products do not provide the required read path or business-specific operations. MCP does not supply the business definitions, permissions, testing or ongoing ownership by itself. Those still have to be designed and operated.

Prerequisite work or no build

Do not add another service when the source data is unreliable, the definition is disputed, access cannot be approved or an existing tool already answers the question well enough. A useful assessment can recommend correcting the prerequisite, using the current route or stopping.

Use the same decision criteria for every option

Coverage: Does the route reach the required systems, records, history and dimensions?
Business meaning: Can it apply approved definitions for measures, periods, ownership, currency and exceptions?
Access: Does each user have an explicit identity path and only the operations and data they need?
Evaluation: Can representative answers be checked against trusted reports or known results?
Operation: Who monitors availability, investigates failures, rechecks answers and manages change?
Compatibility and exit: Which assistant plans, provider settings and hosting choices are required, and how can the route be changed or closed?

Make the route decision before the build decision

The AI Analytics Assessment compares these options for one use case. It records the source and access review, the evaluation plan, the preferred route, material assumptions and the factors that would determine the scope of any later work.

If a build is justified, the work then follows Assess, Build, Run: agree the route, implement and test only what is needed, then maintain it as a managed service. This keeps the technology choice tied to the business question throughout its life.