Application packaging teams are being asked a fair question: if you bring AI into packaging, what happens to your data? It is exactly the right thing to ask. The mistake is to conclude that AI-assisted packaging and real data control cannot coexist.
They can, and for us that is an architectural decision rather than a marketing line. We built EtherApps Forge so AI-assisted packaging runs inside your environment, on your tenant, under your governance, which means your data stays yours. This post explains the thinking behind that choice: why we deliberately did not build a SaaS packaging platform, and how governed AI packaging works when the customer owns the infrastructure.
We deliberately did not build a SaaS packaging platform
The obvious commercial move would have been to build a multi-tenant SaaS packaging service: customers upload their applications to us, our cloud does the work, and everyone's data flows through our pipeline. It is a common model, and it is exactly the model that creates the data risk people are right to worry about.
We chose the opposite. Forge enables customers to build their own packaging solutions on their own tenants. The application binaries, the capture evidence, the packages, the AI prompts, and the outputs all stay inside the customer's environment. You own the infrastructure. You control the boundary. Nothing has to leave your tenant for a package to be produced.
That decision costs us the convenience of a central data lake, and we are comfortable with that. Control and security for the customer matter more than operational convenience for us.
Governed AI with Azure AI Foundry, inside your boundary
AI-assisted packaging still needs a model. The question is where that model runs and who governs it. Forge is built to use Azure AI Foundry within the customer's own tenant, with the protections that make enterprise AI safe:
- Customer-owned infrastructure – The Foundry resource, the model deployment, and the network sit inside the customer's Azure subscription. We do not proxy your prompts through a shared service.
- Private networking and access control – Private endpoints, network isolation, and role-based access keep inference traffic inside your boundary, subject to your Conditional Access and logging.
- No training on your prompts – Azure AI Foundry and Azure OpenAI do not use your prompts, inputs, or outputs to train the underlying models. Your packaging context stays yours.
- Your compliance boundary – Data residency, retention, and policy follow your tenant, not ours, so the same controls you already apply to Microsoft 365 and Azure apply to packaging AI too.
This is the point the "public LLM" argument misses. Using AI does not mean sending client data to a public model. With Forge, the model is one the customer chose, deployed, and governs, running where their other regulated workloads already run.
We do not use customer data, and we never train on it
Because there is no SaaS packaging platform, there is no central pipeline quietly ingesting customer applications. We do not collect your binaries. We do not harvest your capture evidence. We do not train any model on the applications you package.
That is not a policy we bolted on. It is the same principle that runs through the whole portfolio. EtherAssist holds one of the strongest data governance and data control policy sets in the industry, and that commitment to keeping customer data safe is the standard we hold every product to. Forge inherits that DNA: your data is yours, and it is not our training set.
Your environment self-learns, and the learning stays with you
Not training on customer data does not mean the tooling stays static. It means the intelligence compounds in the right place: inside the customer's controlled environment.
Once a customer environment is set up, it self-learns and improves every time you package an app. Patterns, fixups, and packaging decisions that worked on your estate make the next package easier, and that accumulated knowledge lives in your tenant, under your governance. The learning happens in a controlled environment, and the data stays safe. You get the benefit of a system that gets better with use, without that knowledge leaving your boundary or flowing back to us.
We are building our own models to run on your devices
Governed Foundry endpoints are one path. We are also building our own models that can be hosted on customer devices, for teams that want the strongest possible control. When the model runs locally, there is no external inference call at all: the packaging intelligence executes on the customer's own hardware, fully inside the customer's perimeter. It is the same design philosophy taken to its conclusion, keeping both the data and the model where the customer can see them.
The testing reality: MSIX cannot be validated headless
There is a practical truth about MSIX that any honest packaging story has to acknowledge. You cannot properly test an MSIX package in a headless container. MSIX activation, launch behaviour, repair, and App Attach mounting depend on an interactive Windows session, so validating a package means doing it on a real Windows surface.
In practice that means one of two things:
- Windows Sandbox for quick, disposable, interactive checks of a single package.
- Fleets of virtual machines under a structured testing plan when you need to validate at volume, across builds and configurations.
At enterprise scale, spinning up and orchestrating that testing by hand does not keep up. This is where purpose-built platforms like Rimo3 earn their place: they are built to handle automated application testing at speed and at the volume large estates demand.
Forge is designed to fit that reality rather than pretend it away. Forge captures the application, applies AI-guided packaging decisions, and produces deployment-ready MSIX, MSI, IntuneWin, App Attach, and App-V outputs, getting each package ready for final testing and sign-off. How you run that final testing, whether it is Windows Sandbox, your own VM testing plan, or an enterprise testing platform, is your choice. Forge produces the package and the evidence; you decide how it is proven and signed off.
The public LLM question, answered plainly
We agree with the principle that client data must never meet public LLMs. That part is not in dispute, and anyone making it is arguing a point we already hold.
Where we differ is the conclusion. The answer to that risk is not to walk away from AI or wrap the discussion in fear. The answer is architecture:
- No SaaS packaging platform, so there is no central pipeline to leak from.
- Governed Azure AI Foundry endpoints inside the customer's own tenant.
- No vendor training on customer data, consistent with EtherAssist's governance standard.
- Self-learning that stays inside the customer's controlled environment.
- Our own models, built to run on customer devices for the strongest control.
If you have seen commentary suggesting that AI-assisted packaging means feeding client applications into a public model, it does not describe how Forge works. Forge was built from the start so the customer owns the tenant, owns the model, and owns the data. That is not a caveat we add later. It is the foundation.
Start with control, not compromise
You do not have to choose between modern AI-assisted packaging and keeping your data safe. With EtherApps Forge you get both, because control is designed in rather than promised after the fact.
Try it free on EtherApps Forge
No credit card. 7-day trial.
Explore MSIX packaging and deployment or review agentic application packaging to see how a controlled, evidence-led packaging operation comes together on your own tenant.