Factory Private
Enterprise AI
On-prem AI development inside your security boundary
September 18, 2026 - 2 minute read
On-prem AI development becomes difficult when the source repository is private but the tools around it expect cloud access. A local agent can still depend on a hosted control plane, external inference, or a public package registry. Those dependencies need separate approval.
Start with the work the team must perform. Identify the repository, build commands, model service, and review process. Then decide which connections the environment permits. This produces a deployment requirement that infrastructure and security teams can test.
On-prem AI development has several data paths
The execution machine is where code is read, changed, and tested. The control plane coordinates work. The model endpoint processes context, while the collector stores approved operational evidence. Putting one component on-premises leaves the placement of the others undecided.
Factory's deployment patterns distinguish cloud-managed, hybrid, and fully airgapped operation. The published comparison below shows why the location of the runtime and the destination of model traffic both matter.
Screenshot of the linked deployment documentation, captured September 18, 2026.
Factory Private places a customer-owned control plane in a VPC or on-premises environment. That arrangement supports customer control over infrastructure and updates. The deployment still needs approved inference, tools, and network routes.
Make on-prem AI development reproducible
Before adding an agent, build and test the repository in the intended environment. Inventory the language runtime, package sources, generated-code tools, and test fixtures. A missing dependency remains missing when Droid runs the same command.
Use the existing artifact process to distribute approved versions. If an update introduces a public download during validation, either supply an internal source or explicitly review that connection. Avoid temporary network exceptions that quietly become production dependencies.
Factory's data-flow documentation explains that file reads and writes remain local, while file content used for inference follows the configured model path. Inspect the service behind any gateway rather than relying on its private hostname.
Bound access before increasing autonomy
Give the initial workflow a disposable working copy and the permissions needed to validate a change. Keep standing production credentials and unrelated repositories outside its reach.
Factory's Agent Safety & Controls includes command restrictions, hooks, and filesystem and network sandboxing. Use those controls with existing infrastructure policy. Keep source-control review requirements in place for the resulting patch.
Test a harmless denied operation alongside a successful task. Confirm that a write outside the workspace or a connection to an unapproved test destination fails. Record the enforcement point, not just the model's explanation.
Assign the operating work
Customer-controlled deployment needs owners for releases, model availability, certificates, and recovery. Record who promotes an update and how the previous configuration is restored. Test recovery in a disposable environment before depending on it during an incident.
Start with a bounded maintenance task and known validation. Track accepted changes, reviewer corrections, and operator intervention. Those measures expose whether the workflow is repeatable or succeeds only with substantial manual help.
The practical acceptance record should connect the approved diagram to the observed behavior. Preserve the artifact versions, endpoint configuration, policy tests, and reviewed result. Expand to another repository only when the team can reproduce that record.
