A practical approach

Governing AI.
Before, during and after deployment.

A powerful model becomes useful when people know what it can do, which data it can use and who is accountable for decisions. Here is how to establish a practical approach in your business.

Let’s assess your context

1. Take an inventory of applications

Gather the tools already in use: chatbots, AI features in software, automations, local models and departmental trials. For each application, record its purpose, owner, users, data processed and connections. A simple inventory is more useful than a generic policy that nobody connects to their work.

2. Choose a clearly bounded use case

Define a task that can be tested, an expected result and a way to assess it. Finding a procedure in an archive and making a decision about a person are not equivalent activities. Start with a workflow whose inputs, controls and potential errors can be understood.

MappAI Valore can help identify opportunities to explore. It does not replace risk analysis or legal classification: its purpose is to focus the discussion on operational priorities.

3. Set boundaries for data, tools and permissions

Establish which documents can enter the system and which actions the agent can perform. Separate testing and production environments, use credentials with appropriate privileges and define who authorises connectors. Even when the model runs locally, check which external services its tools call.

With a custom AI solution you can design these boundaries before integrating systems. Access should follow the system’s function rather than the convenience of granting every available permission.

4. Design human oversight

Decide which outputs need review, which actions require confirmation and how to stop a workflow. Define what happens when sources are missing, answers are uncertain or errors occur. Escalation should lead to an identifiable person or procedure.

5. Validate using examples from real work

Prepare representative and difficult cases: incomplete documents, ambiguous requests and data outside the expected context. Assess quality, sources, time and the review workload. Keep a baseline before changing the model, prompts or connectors.

In the Brain Company project, operational memory, sandbox testing and validation form part of the described architecture. Actual availability needs to be checked for the release and configuration being adopted.

6. Train and update

People need to know which information they must not enter, how to read sources and when to request a review. Connect training to roles: everyday use, supervision, administration and development have different needs. Update materials and responsibilities when the system changes.

The AI training and AI literacy can support the introduction of new workflows. The EU AI Act guide provides introductory regulatory context; the technical process alone does not amount to certification.

7. Monitor and maintain a way back

Define how to record incidents, collect feedback and review access. Version changes and prepare a recovery path. An evolving solution needs to be comparable with its previous version, particularly when its behaviour changes around documents or operational actions.

A concrete first outcome

At the end of an initial phase, at least four things should be clear: the selected use case, the permitted data and tools, the person responsible and the acceptance criteria. From there, you can build a prototype and verify its value before extending the project.

Do you need ongoing AI support?

With AI Architect in Residence, you can connect process analysis, roadmaps, development and training through ongoing support.

Discover Ergoware AIR