Local AI becomes part of business digitalisation when its outputs enter a controlled workflow: classifying an enquiry, preparing a CRM summary or drafting a response from an approved catalogue. The model runs on business equipment, while the application decides what information it receives and which operations are allowed. Integration starts with a precise process and a verifiable result.
Choose an operation with clear inputs and outputs
A suitable first project can turn incoming messages into classified enquiries with a summary and suggested department. Another can prepare a preliminary quotation from approved products and conditions. For an online shop, an internal assistant can explain order status using information available to the operator. Each version requires its own fields and rules.
Define who starts the operation, what data it may read and who accepts the output. Begin with reading and proposing. Saving records and sending messages are separate steps with explicit rules. This lets the business assess the model's usefulness before connecting the initial trial directly to uncontrolled changes in operational systems.
Integration with local inference
- Request
An identified CRM or application user.
- Service
Checks access and selects context.
- Local model
Produces a classification or proposal.
- Application
Validates and displays the result for the next step.
Separate local inference from connected applications
An integration service can receive a CRM request, select permitted data and call the local engine. If the shop or CRM is externally hosted, that connection forms part of the data flow. Local describes where the model executes; the architecture separately records application hosting and how information moves between components.
For a pilot, the AI workstation can use an 8B instruct model and one active request. The integration service manages authentication, time limits and job status. Within the business network, only authorised components can reach the engine. User browsers do not receive CRM secrets or freely choose internal service addresses.
Send the context required for the operation
For message classification, provide the message and approved category list. For a sales response, provide relevant catalogue passages and the applicable policy. Avoid loading an entire customer profile when only a few fields are needed. Internal identifiers can remain in the application, connected to the request through a controlled reference.
Before calling the model, check the user's permission for the record and the state of its data. An operator may see their team's orders without access to every company order. The model receives already-authorised context; it does not determine who may read a record. Test those rules with accounts and cases having different permissions.
Request a structured proposal
The output can follow a schema containing enquiry type, summary, identified fields and review status. Ollama supports structured output using a request-supplied schema. The application checks the response, including field lengths, permitted values and missing information. Reject a category absent from the business catalogue or route it to review.
For a quotation, prices, stock and calculations come from authorised systems. The model can draft wording and explanations using those values. The application calculates and validates totals, checks conditions are current and records the catalogue version used. This separation makes results traceable after catalogue changes.
Who determines what
- Authorised systems
Stock, prices, conditions and identifiers.
- Model
Summary, classification and proposal wording.
- Application code
Calculations, permissions, schema and approval.
Give tools narrow permissions
A model proposing a tool call produces an operation request. Application code checks the tool, arguments, user and approval rule. An order-status reading function can be provided without general SQL access. For modifications, separate permitted fields and enforce business conditions within the integration service.
A message or document note may contain instructions directed at the model. Treat that text as input data with limited authority. Manage tool lists, secrets and approvals outside the content being read. For every consequential operation, retain the validation result and approval required by business policy.
Recover without duplicating operations
Assign each task a unique identifier and statuses such as waiting, active, proposed, approved and complete. If the model or connection stops, the service knows the latest confirmed status. Before retrying a save, check whether the operation with the same identifier was already executed. This mechanism is called idempotency and belongs in the application.
For a task sending a message, retain the draft separately from sending confirmation. A timeout does not establish that sending failed. Recovery begins by reconciling the outcome in the target system. Operational logs retain identifiers, versions and statuses needed for that check, under defined access and retention rules.
One operation, including after recovery
- Identifier
The same case retains its operation key.
- Confirmed status
Check what the target system actually saved.
- Resume
Execute only the unconfirmed authorised step.
Acceptance tests cover the complete workflow
Test the ordinary case, missing data, denied access, invalid output, timeouts and recovery. For each trial, inspect both the proposal and the resulting CRM or shop state. Measure time to an accepted outcome and human review effort. These observations establish whether the integrated process helps the team beyond text-generation speed.
WebHat uses a customised local AI system and provides consultancy on connecting models to business processes. A business automation project with AI integration defines data, tools and approvals. Where a workflow needs specific interfaces or rules, a custom AI application can bring those components into a manageable system.
Questions about business application integration
Does the model need direct access to the CRM database?
A service with bounded functions can provide approved fields and operations only. Authorisation and validation remain in application code.
Can an externally hosted shop be connected?
Yes, through an authorised integration. Document the connection and transferred data while keeping shop hosting distinct from local inference.
Who verifies prices and totals?
The application uses the approved catalogue and commercial rules and performs calculations in code. The model receives the information needed to draft a proposal.
How should an interrupted connection be handled?
Check the operation's status and identifier, reconcile any saved result and resume only the unconfirmed step under the idempotency rule.
