Methodology & Process
From Private and Sovereign AI to Trusted Agentic Action
A Practical Framework for Agentic Transformation
Eastgate Software - German Engineering Standards. Enterprise-Grade Results.
From Private and Sovereign AI to Trusted Agentic Action
A Practical Framework for Agentic Transformation
Keeping control of your data is one decision. Letting an AI agent carry out the next step is another. This paper connects the two: how deployment choices shape what an agent is allowed to do, what evidence to require before production, and how to measure the full cost of a result the business accepts.
Eastgate Software 
Introduction
Putting artificial intelligence (AI) into daily work requires deciding how much control your business needs over the systems it will depend on. Reliance on foreign technology providers raises questions about who operates those systems and protects internal information. Today, an assistant typically draws on that information to answer a question, while a person still decides what to do next.
When the system has permission to carry out the next step, the decision changes completely. An AI agent uses a model to choose actions through software tools. Its permissions determine which records it can change. An approval has to apply to the action that actually takes place, and a failed action needs a way back to a person who can resolve it.
The rules protecting internal information must hold as the agent moves from reading to action. Each tool it uses must respect restrictions on where data goes and who can access it. This connects private and sovereign AI with agentic process transformation: the environment must support both the information the agent needs and the work it is allowed to perform.
This paper follows that connection from a useful answer to a business result you can stand behind. Drawing on implementation experience and expert perspectives, it explains:
- How deployment choices shape agent authority
- What evidence to require before production
- How to assess the cost of the whole process
Why are deployment control and process transformation converging?
Choosing an AI provider affects how much control a business keeps over a live workflow. The service determines which model infrastructure the workflow relies on and the options available for processing its data. If changing providers means rebuilding integrations, a supplier change also becomes a process-change project.
Keeping a workable alternative is one way to limit dependence on a supplier. In Europe, the debate about sovereign AI includes interest in alternatives to providers based in the US and China. In September 2026, CNBC reported that Mistral raised €3 billion and described its positioning as a non-US, non-Chinese option amid growing interest in sovereign AI in Europe and elsewhere. Control over the service still leaves the business to establish whether the agent will perform its work reliably.
Deployment control
Who can access your data? What would it take to switch providers and keep the workflow running? The provider's location matters, along with who operates the service and what your contract allows.
Process
The process owner needs to know whether the workflow follows the required approvals and produces a result the business accepts.
Organizations that already run agents in pilots meet the same question when they try to scale. Deloitte's 2026 study of US business leaders measured how widely that concern is shared:
of US leaders piloting agentic AI say an inability to trust and govern agents is a barrier to scaling.
A rule about where data can go must cover the tools an agent calls, as well as the model itself. The process must determine what the agent is allowed to do with that information. Use both requirements to choose the AI environment and design the workflow.
How do you define the control requirement before choosing the platform?
Start with the control your business needs, then compare deployment options against it. Private AI, sovereignty and data residency describe different aspects of control. Ask for evidence of the controls each deployment option actually provides.
Private AI
uses a controlled environment for an organization's models and data.
Sovereignty
concerns who has control, which laws apply, and the terms on which the system operates.
Data residency
describes where data is stored or processed.
Hosting in a chosen region addresses only the location commitments that service makes. You still need to assess who can access the data and operate the system.
BNP Paribas connects deployment choices to the decisions people retain in sensitive banking work. Its partnership with Mistral includes developing on-premises AI for Know Your Customer (KYC), the process banks use to verify customers’ identities and assess risk. The approach automates routine steps while experts validate risks and decisions. It sits within a broader strategy that uses multiple models, with choices guided by data sensitivity and geography as well as performance.
Your requirements need to cover every service that receives the workload's data. Assessing which outside services you can rely on takes both legal and technical review: specialists assess the laws and contract terms, while the technical team examines the safeguards. Use the following decisions to specify the evidence you need.
| Decision | What to establish |
|---|---|
| Data handling | What data each service receives, where it keeps copies and for how longA map showing where data goes, retention settings and any exceptions |
| Operational access | Who can administer systems or inspect sensitive contentAccess permissions, support procedures and records of administrator activity |
| Model flexibility | What you need to run, update, or replace a modelLicense terms, required infrastructure and a tested process for switching models |
| Business continuity | How work continues if a service fails, or you change providersRecovery test results and a practical plan for moving to another provider |
Data handling must cover every copy of the information used in a workflow. A prompt or a passage retrieved from a document can contain the same sensitive facts as the original file. Stored chat history creates another copy. Embeddings are numerical representations used to search for relevant content. They need a handling policy too. Logs and backups belong on that map alongside test datasets.
Operational access
The access policy should specify who can administer the service or inspect sensitive content, under what conditions, and how their activity is recorded.
Model flexibility
A replacement model can make different choices within the same surrounding software. It needs to pass the workflow's tests before use.
Business continuity
An export file helps only if another environment can use it to restore the process.
Air-gapped deployment
If external network access is ruled out, an air-gapped deployment provides that isolation. It also changes how the team obtains updates and support, because those activities must preserve the disconnected environment.
Why redesign the work before assigning an agent authority?
Agentic process transformation redesigns a business process around the work people and agents will perform. Discovery should establish how people make decisions today and what evidence a completed case needs. Those findings connect the deployment's control requirements to the actions an agent is allowed to request and the decisions people retain.
The people doing the work help explain what the process map leaves out. Shlomi Yehezkel, chief technology officer at Cygon, describes the gap this way: “In my experience, process documentation describes the steps but misses the expectations.” His advice is to establish what a good result looks like and what domain context the system needs before building it. Test cases written at that stage give the team a way to judge whether it meets those expectations.
Judgments
Staff need to recognize missing information and choose between conflicting records before they can make a decision.
Handoffs
If a request waits because another team holds information needed for approval, automating its transfer does not settle the approval.
Approvals
The process owner should establish who can take over each approval and how waiting cases reach them.
Completion
A successful tool call is only evidence about that call. A later step could still reject the change and leave the case unfinished.
Celanese, a chemicals and specialty materials manufacturer, gives plant staff an assistant called JO.AI, built from pre-trained agents for specific use cases and user roles. The agents use plant data, including engineering drawings and pictures, to guide operator rounds and recommend maintenance work.
For example, Celanese presented a maintenance task in which an agent suggested a likely cause from a technician's photo and answers. The work order changed only after the technician accepted the recommendation. Celanese says it was not looking to take humans out of the loop. A workflow built this way should also record who accepted each recommendation and the evidence behind it.
A process with clear completion criteria also needs someone accountable for accepting the result. The process owner retains that responsibility after launch. Engineering maintains the workflow's behavior and reliability, while security reviews the access it needs and the risks that follow.
| Owner | Responsibility once the workflow is live |
|---|---|
| Business process owner | Sets acceptance criteria, approval policy and exception priorities; accepts the business result |
| Engineering and operations | Maintains integrations, records workflow state, restores failed work and manages releases |
| Security and risk | Reviews access and data controls, assesses abuse scenarios and coordinates security incidents |
The process owner needs to be able to change acceptance criteria when the work changes. That includes deciding which exceptions are acceptable and which cases must return for review. Engineering needs a way to put those exception decisions into practice. When a retry cannot resolve a failure, the operating team needs to know what remains unfinished and how to recover it. Security needs enough evidence to investigate how the workflow reached that state.
Yehezkel recommends bringing these owners together from the start, while the team is deciding what data the AI can use and where it goes. Their involvement needs to continue after launch. A new model or wider tool permission can change business behavior even when the screen looks the same, so the people accountable for that behavior should review it before release.
How do you design an enforceable path from answer to action?
The responsibilities established during discovery need to become controls the workflow can enforce. Instructions in a prompt can guide an agent's behavior, but they do not enforce access rules. Before a tool acts, a separate service should check the user's rights and the current workflow state, along with any approval the action requires.
Grant the agent authority according to the consequences of each action. Reading a document calls for different controls from changing a financial record. A reversible update can justify a different approval policy from an irreversible action. The evidence for each operation should determine whether the business grants more authority.
Permission to read information does not authorize an agent to change a system. A retrieval service should pass source content to the model only when the user has the right to read it. The agent then uses that context to request a tool action. A separate policy decision determines whether that action is allowed, and the receiving business system should retain its own access checks.
Whose authority the agent uses
- The person who started a task should be identifiable alongside the software identity that calls the tool.
- That identity needs only the rights required for its work.
- Short-lived credentials limit how long delegated access lasts. Shared administrator credentials make it harder to trace actions or withdraw one agent's access.
An action that requires approval must remain tied to what the person reviewed. The reviewer needs to inspect the actual change and its destination, rather than rely on an agent's summary. If the agent changes a recipient or amount afterward, the earlier approval does not authorize that revised action. The workflow needs to retain what was approved and send it back for review when the relevant details change.
Once an authorized action is underway, the workflow must retain enough information to resume it or explain what happened after an interruption. This retained information is its durable state. If a request times out, the receiving system could have accepted the action before the connection broke. A retry could repeat the action unless the workflow first establishes whether the original request succeeded.
Some systems prevent that through idempotent requests. Repeating the same identified request does not create a second business action. Where that protection is unavailable, engineering needs another way to detect duplicates or pass the uncertain case to a person. Recovery must account for actions that cannot be undone.
SaaStr founder Jason Lemkin reports that a third-party agent deleted sales opportunity records in Salesforce after receiving write access. The team restored the records from a separate snapshot outside that agent's reach. Lemkin says the agent supplier had no rollback option. After the incident, SaaStr changed its approach so new agents start with read-only access and critical systems undergo a test restore before an agent receives permission to change them.
A recovery copy needs protection from the same permissions that allow an agent to change live records. Otherwise, a faulty action could affect both the working data and the means of restoring it. Testing the restore also reveals what would be missing since the last copy and who must reconcile later changes before normal work resumes.
Prompt injection
Prompt injection occurs when content supplied for an agent to read attempts to redirect its behavior. Even when the model runs privately, those instructions could lead it to request a tool action that sends sensitive content to an unapproved service. Controls on tool access and destinations must hold even if the model follows the instructions.
What does AmatriumGPT show about controlled access to knowledge?
AmatriumGPT is an AI knowledge assistant we built for Amatrium, a materials company based in the US. The project helps engineers find answers across a library of technical documents.
We built the service on Azure for engineering and materials information. Staff can follow citations to inspect the sources behind an answer. Our enterprise knowledge hub case study describes the implementation and its reported outcome.
Amatrium estimates that staff spend 30 to 40% less time on document queries than they did with manual search.
In his account of the project, Chuong Phung, our AI technical leader, describes technical knowledge scattered across manuals, test reports and other records, including scanned documents. Finding an answer meant knowing which file to open and reading it manually. He identifies the main difficulty as “retrieval and verification, not storage”: finding the relevant passage and judging whether it supported the answer.
Zero data retention (ZDR)
- Chuong says requests are restricted to endpoints selected for zero data retention (ZDR), alongside a requirement that customer data is not used for provider training.
- ZDR concerns whether the model provider retains request content after processing; the application's own logs need separate controls.
- ZDR does not show where data is processed. To assess sovereignty, you still need to examine how the service runs and which outside systems it depends on.
Model changes require fresh evidence that the knowledge service still works as expected. Chuong reports tests for answer quality and processing time before release, alongside compatibility checks. Citations let engineers trace an answer to its source and judge whether the passage supports what the model has said.
Capacity
That privacy requirement narrowed the endpoints available for each model, which affected capacity planning.
On-premises option
For a future build, Chuong would plan a local or on-premises option earlier for customers whose data must stay within their infrastructure.
Evaluation
To make those tests easier to repeat, Chuong would build an automated evaluation set earlier in a future project.
Monitoring
Chuong says the team uses Azure Monitor and Sentry to monitor response time, with model-level token tracking and spending caps to help control cost.
AmatriumGPT gives engineers cited answers with controlled access to internal knowledge. An agent that changes business records would also need action permissions and approval rules. For example, updating a manufacturing work order requires authority beyond permission to read its contents. Before granting that authority, test how unfinished work reaches a person who can recover it.
What evidence should you require before production?
Before production, test the result and the actions used to reach it. The result must meet your business's acceptance criteria. Access rules must hold throughout the workflow, and failed cases must reach the people responsible for recovery.
The test set should reflect the work operators need help with. Yehezkel recalls an AI event-analysis tool that looked promising in an early demonstration but struggled with harder questions in daily use. Use cases with missing evidence or conflicting records to test how the workflow handles doubt. Yehezkel also calls for tests for invented answers, known as hallucinations, and for responses that contradict each other.
Yehezkel recommends using operators' questions and resolved cases to improve context over time. Updating approved source material and tests is one way to do this without training a provider model on customer data.
| Failure case | Required behavior |
|---|---|
| Unauthorized instructions in retrieved content | The workflow must refuse prohibited actions and record the attempted deviation.Records in the destination system must confirm that no unauthorized change occurred. |
| Permission removed during a task | Later retrieval and actions must respect the changed permission.Include cached context and delegated tool access in this test. |
| Timeout after a write request | The workflow must determine whether the write occurred before attempting it again.Test the uncertain state in which the receiving system accepted the action but returned no confirmation. |
| Missing evidence or conflicting records | The case must reach a visible exception queue with enough context for review.The reviewer should be able to identify the unresolved decision and resume the work. |
| Unavailable model or tool | Work must pause or follow an approved fallback without widening access.Test the fallback against the same information and action boundaries as the normal path. |
Before production sign-off
- The agent's account of each test needs to match the resulting business state.
- Case identifiers should connect tool requests and results to records in that system.
- Rerun the affected tests when the model, retrieval rules or tool permissions change.
- Before launch, decide what will cause it to pause and who can suspend it.
How do you measure accepted outcomes and the work required to achieve them?
Count a case as accepted only after it meets the business's acceptance criteria. A model call can finish before the business accepts the work. Include the effort of assessing and correcting its output in the cost.
A useful operating metric is:
accepted case total included cost for the measured workload cases from that workload that meet the acceptance criteria
The costs you include determine what the metric tells you. Counting only the charges for model responses gives you an inference-cost measure. Operating cost also includes relevant infrastructure and tool charges, together with human review and exception handling. State the measurement period and explain how you treat implementation costs. Report them separately or allocate them over a disclosed period and workload, without counting the same cost twice.
- Inference
- Infrastructure and tools
- Human review
- Exceptions and recovery
Unit cost becomes more useful when you can explain where the effort went. Cycle time shows how quickly work finishes, while human review time reveals whether the workflow has moved effort onto another team. Exceptions and rework help explain those results. Breaking the measures down by case type prevents routine work from hiding a difficult part of the queue.
Failed attempts
Failed attempts and recovery remain part of the cost even though they do not increase the count of accepted cases.
Review quality
A shorter queue is useful only if the business still identifies decisions that require a person.
To judge whether those results improve on the existing process, compare similar workloads. A pilot that receives only complete, routine inputs will not reveal the cost of handling unresolved production cases. Changes in demand matter too. Record them so you can see whether the workflow improved or the work simply became easier during the pilot. The measurement window should allow enough time to confirm outcomes, with unfinished work reported separately.
Any time saved in that comparison first creates capacity that the business must decide how to use. It could help clear a backlog or complete more work with the same team. Financial savings need evidence of reduced or avoided spending. Without that evidence, hours saved should remain a capacity estimate rather than a claim that operating costs have fallen.
Savings and contracts
- If supplier fees depend on outcomes, the acceptance rules also need to carry into the contract.
- Meeting a contract target alone does not show that the deployment has paid for itself.
When should you fund the next stage?
You can judge the next investment when a process has a measurable outcome and an owner who can change how the work runs. The current workload and its exceptions give that owner a basis for choosing which work to test and what would justify wider use.
The initial design should translate that work into a data-flow map and an action policy. Together, they show what the agent can read and what it is allowed to do. These requirements help you choose where the system should run. If it needs isolation, the design should also account for keeping it updated and supported.
A pilot can then test the process with restricted authority against those requirements.
- Its results should show whether the business accepts the output and how much recovery or review it takes to get there.
- Unclear approvals and conflicting records are process problems to resolve before expanding access.
- A more capable model cannot decide who in the business has the right to approve a transaction.
At Eastgate, we connect these decisions through our Private and Sovereign AI services and Agentic Process Transformation services. We assess models and deployment options against the control each workload needs. That includes private cloud, on-premises and air-gapped environments where appropriate. We map the work before building permitted system updates and approval steps. We then test recovery and assess the workflow against the business's acceptance criteria.
The handover is complete when your team knows how to maintain the integrations and assess later changes, and has demonstrated that it can recover failed work. Before production, clarify which operating responsibilities stay with your team and what managed operations will cover.
Conclusion
Make your next step a joint plan for the process and the AI environment it needs. Use these four decisions to structure that work.
- 1
Select a process with a clear outcome.
Work with its owner to establish today's cycle time and review effort. Define what must be true for a case to be accepted.
- 2
Choose deployment around the data requirements.
Map where information goes, including tool calls and support access. Use those requirements to compare deployment and partner options, including how you would replace a provider.
- 3
Design how people and agents will work together.
Specify which actions agents can take and who approves consequential decisions. Let staff test real cases and practice taking over unfinished work before launch.
- 4
Use a limited pilot to guide the next investment.
Assess accepted outcomes and the full cost of reaching them. Expand when the workflow meets its acceptance criteria and your team can operate and recover it.
Frequently asked questions
What is the difference between private AI, sovereignty and data residency? +
Private AI uses a controlled environment for your models and data; data residency describes where data is stored or processed. Sovereignty covers who controls the system and which laws and terms apply, beyond where the service is hosted.
Why should private AI and agentic process transformation be planned together? +
An agent can read through one service and act through another. Plan both together so data restrictions cover the model and its tools, and access rules govern each requested action.
Can instructions in a prompt control what an AI agent is allowed to do? +
Prompts guide behavior but do not enforce access rules. A separate service must enforce permissions and required approvals before a tool acts, and the receiving system must retain its own access controls.
What should be tested before an agentic workflow reaches production? +
Test that the result meets your acceptance criteria, access rules hold and a person can recover failed work. Include hostile instructions in source content, revoked access, uncertain write results, conflicting records and service failures.
How should the cost of an agentic workflow be measured? +
Divide the total included cost for a measured workload by the cases that meet its acceptance criteria. Include failed attempts, review and recovery, and state the period and how you treat implementation costs.
Read the Full White Paper
Detailed framework, implementation methodology, and actionable insights - available instantly with your business email.
About Eastgate Software
Eastgate Software is a strategic engineering partner headquartered in Hanoi, Vietnam, with offices in Aachen, Germany and Tokyo, Japan. With 200+ engineers, 93% team retention, and 12+ years of delivery excellence, we build mission-critical systems for clients including Siemens Mobility and Yunex Traffic.
Our ACDC (Agent-Centric Development Cycle) methodology combines German engineering discipline with Vietnamese engineering talent to deliver enterprise-grade results across Intelligent Transportation, FinTech, Retail, and Manufacturing.
Contact: [email protected] | (+84) 246.276.3566 | eastgate-software.com
Let's Work Together
Tell us what you're building. Our engineers will respond within 1 business day with a concrete next step - no sales script, no obligation.
- Email[email protected]
- Phone(+84) 246.276.3566
- Response TimeWithin 1 business day