Rolling out AI in an organisation does not start with choosing a language model. It starts with deciding what data the system may process, which applications it can access and who is accountable for the operations it performs.

This distinction is fundamental. A chat for a single employee can be launched in the cloud in a few minutes. An AI environment connected to the company's document repository, ERP, CRM, ServiceDesk or user directory requires a harness — a specialised intermediary layer that manages models, permissions, tools and audit.

1. Start with the process, not with choosing a model

The question “Which LLM is the best?” comes up in projects far too early. The model is an interchangeable part of the architecture. First, describe a specific business process:

  • Who initiates the task and which systems (ERP, Jira, SharePoint, ServiceDesk) the employee uses.
  • Where the bottlenecks arise and what a potential mistake would cost.
  • Which activities rely on synthesising knowledge, and which on modifying data in transactional systems.

A good pilot process recurs regularly, relies on data the organisation has already collected and does not require full agent autonomy at the outset. It starts with searching for information and drafting responses, which makes it possible to measure reliably how long a task takes before and after the rollout.

One example is handling internal IT/HR requests: in the first step, the assistant searches the procedure base and proposes an answer. In the next step, it gets secure read access to the request status in the ServiceDesk system. Only in the last stage does it prepare a change to the request's parameters, which requires the operator to click “Approve”.

2. One platform, four classes of solutions: from chat to agent

An organisation does not have to roll out separate tools at each stage of AI maturity. In the PLC ONE architecture, each of these classes is simply a matter of configuration within a dedicated Project (an isolated workspace with its own prompt, knowledge base, tools and budget):

  1. 1. ChatGeneral knowledgeDrafting, language, no access to ERP/RAG
  2. 2. RAG / Deep SearchCompany knowledge baseDocuments, OCR, tables, citations to sources
  3. 3. Assistant (Project)Department / ProcessPrompt, rules, roles, choice of models and permissions
  4. 4. Agent (MCP)Tools and integrationsRead/write in ERP/CRM, sandbox, human-in-the-loop
Figure 1: Four classes of AI solutions within the unified PLC ONE Project architecture.

General chat

A communication gateway to language models. It is used for drafting letters, translations and brainstorming. It has no access to the organisation's internal resources.

Chat with a knowledge base (RAG and Deep Search)

The conversation is extended with the company's file repository (PDF, DOCX, XLSX). The platform does not send whole documents to the model; it extracts precise fragments. The Deep Search mechanism performs a multi-step analysis of complex tables, manuals and regulations, pointing to exact citations of the sources.

Dedicated assistant (Project)

An independent ecosystem configured for a specific department (e.g. quality control, finance, onboarding). It has a dedicated system prompt, specific user permissions and assigned models (e.g. an inexpensive model for classification and an advanced model for synthesis).

Agent (MCP tools and Sandbox)

The agent can perform tasks in external systems: query a database via an API, retrieve records from the ERP, run calculations in an isolated Sandbox environment and generate an interactive report (an Artifact).

Table 1: Solution level, use case and control mechanism in PLC ONE
Solution levelTypical business useControl mechanism in PLC ONE
General chatDrafting letters, translations, working with textModel gateway, prompt filtering, ZDR policy
RAG / Deep SearchFinding procedures, analysing regulations, standardsOCR, multi-step Deep Search analysis, source verification
Assistant (Project)Onboarding, bid support, departmental helpdeskProject isolation, RBAC role control, dedicated prompt
Agent (MCP)ERP reports, status changes in CRM/JiraMCP standard, Human-in-the-loop mode, full audit log

3. Data flow control: self-hosted, ZDR and local models

Deciding where processing takes place does not have to be a compromise between functionality and security. In the PLC ONE architecture, the platform is installed in the customer's environment (self-hosted on-premises in Docker containers / a virtual machine). Files, RAG indexes and conversation history stay exclusively within the organisation's internal LAN.

At the model layer, the architecture supports four scenarios:

  • External models with Zero Data Retention (ZDR): Queries go to trusted providers that guarantee queries are not stored (ZDR) and models are not trained on customer data, with processing enforced in the EU region.
  • Local data protection (DLP): A DLP service running on the customer's server analyses the prompt before it is sent outside and automatically masks PESEL numbers (Polish national ID), NIP tax numbers, IBAN account numbers and personal data.
  • Local models (on-premises GPU): For processes with strict confidentiality requirements, models running directly on the customer's servers (e.g. Bielik, Llama) are connected.
  • Full air-gap environment: An installation completely cut off from the internet, in which text generation, embeddings, OCR and reranking run exclusively on local computing resources.

4. Permissions and the MCP standard: the agent in the user's context

The most serious architectural mistake when integrating AI with IT systems is using a shared technical account with administrator rights. In such a setup, a user could use the chat to extract data they have no access to in the source system.

A controlled environment uses two mechanisms:

  1. User identity context (User Context): The platform integrates with the company's identity directory (Microsoft Entra ID, Active Directory). When it calls a tool in an external system, the agent acts in the context of the signed-in employee's account and inherits their permissions.
  2. The MCP standard (Model Context Protocol): An open standard for orchestrating tools. Every operation that an MCP server makes available to the model has a precisely defined mode: automatic (safe read), requires approval (data modification) or blocked for the given Project.

5. Separating reads from writes (Human-in-the-Loop)

Deploying an agent does not mean handing it full decision-making power. For operations that change the state of business systems, one rule applies: AI proposes, a human decides.

  1. 1User requeste.g. “Update the status of request #124”
  2. 2Read & Analysis (MCP)Retrieving context from ServiceDesk / ERP
  3. 3Change proposal cardGenerating a real-time preview of the operation
  4. 4Human approvalThe employee clicks “Accept”
  5. 5Write & Audit LogExecuting the write and recording the event
Figure 2: The Human-in-the-Loop control model for write operations in the MCP standard.

Instead of modifying a record in the ERP or CRM directly, the agent prepares a clear change summary card in the conversation window. Only after an authorised employee clicks the authorisation button does the tool execute the transaction in the target system, and a full record goes to the audit log.

6. Full audit of operations and telemetry

Audit in a professional AI environment goes beyond the conversation history itself. An enterprise-grade event log must record the full chain of execution:

  • The user's identity and the Project in which the action was invoked,
  • The list of documents retrieved by the RAG module as context,
  • The DLP rules applied to mask sensitive fields,
  • The name and version of the model that prepared the answer,
  • All MCP tools called, together with the parameters passed to them,
  • The details of the person who approved the write operation, and the execution status in the external system.

7. Economics: per-Project licensing and the token budget

The common per-user licensing model (e.g. USD 25–30 per month for every account) becomes a barrier when trying to make AI available to the whole organisation — especially to operational staff, logistics or warehouses, who use the tools only occasionally.

The PLC ONE architecture separates the platform layer from model consumption:

  • Platform licence per Project: The fee is based on the number of departmental assistants (Projects) running, not on the number of users in the company.
  • Actual model consumption (pay-per-token): The organisation pays only for the tokens actually processed. Fast and inexpensive models are assigned to auxiliary tasks (spreadsheet descriptions, summaries, routing), and advanced models work only on complex analyses.
  • Hard budget limits: The administration panel makes it possible to set monthly cost limits per organisation, group and individual Project, with automatic blocking once the threshold is exceeded.

Summary: a plan for a safe rollout

Moving from a pilot to a production environment does not require a technological revolution or swapping tools at each stage of development. A well-chosen harness architecture lets the organisation develop its AI capabilities in a way that is controlled, secure and predictable in cost.