AI that gets work done.

This is exactly the question a regulated buyer should ask, and it's built into how the chats run, not bolted on. Chats require each employee's consent before they start, and run on Onky's EU infrastructure (region europe-west1) with data kept in region. The raw transcript and any audio are parsed in the moment and then discarded: what Onky retains is a sanitised, de-identified record of how the work runs, with no names, no verbatim quotes, and no emotion, and it is never used to train models. The models themselves are open-source and run inside that same EU infrastructure, so nothing is sent to third-party AI labs. That record is access-controlled and audited, which is what lets your DPO answer purpose-limitation, access, and deletion questions with evidence, and it is deletable on request with retention defined in your pilot agreement. Because the agent processes personal data about your employees during the chat itself, Onky acts as your data processor under a DPA agreed as part of your pilot. If you need a sovereign deployment for this data, managed EU cloud is available today, with private VPC next and on-premise and air-gapped deployments available on request.

Onky's AI agent chats with each employee about their day-to-day work, asking follow-ups the way a senior consultant would. Chats run on Onky's EU infrastructure (hosted in region europe-west1) and require consent before they start. The recordings and raw transcript are never stored: they are parsed in the moment into a de-identified record of how the work runs, then discarded. What you keep contains no personal data and no emotion, is never used to train models, and is deletable on request. The output belongs to you: the foundation your assistant answers from and builds on, governed like everything else.

Today the platform runs on Onky's managed EU cloud (region europe-west1), with your data isolated, kept in region, and never used to train models. The models are open-source and run inside that same infrastructure, so your data never leaves it for third-party AI labs. Private VPC deployment is next on the roadmap, and on-premise and air-gapped deployments, with Onky's policy engine, the Kernel, and all data processing fully inside your own perimeter, are available on request. If sovereign deployment is a requirement for you, book a demo and we will scope it with you.

Onky is built around what the EU AI Act asks regulated operators to demonstrate. Data minimisation starts at capture: employee chats are parsed into a sanitised, de-identified record of how the work runs, and the raw transcript and audio are discarded, so no personal data or emotion is stored. Every build, deployment, and model call runs through Onky's policy engine, the Kernel, and is logged end to end, so you have a complete audit trail, transparency over how automated decisions were made, and human oversight on every action through your policy gates. Onky does not certify your compliance: that depends on your own use case and obligations. What Onky gives you is the governed architecture and the evidence to demonstrate it, produced by the system itself rather than reconstructed after the fact.

Onky runs on open-weight models, the open-source model families you can host yourself, inside EU infrastructure Onky controls (region europe-west1), with every model call logged and policy-checked by the Kernel, our policy engine. Your prompts and data never reach third-party AI labs, and are never used to train models. Because the models are self-hosted, the brain can also run on-premise and air-gapped, fully inside your own perimeter, where proprietary-API models can't follow: both are available on request and scoped on the call.

Not yet, and we will not pretend otherwise. What is true today: Onky signs a DPA at pilot signing, runs on EU infrastructure it controls, never trains models on your data, and is built around the EU AI Act's obligations. ISO 27001 certification and a SOC 2 Type II audit are in progress; the regulatory status section on this page shows exactly where each stands, and the wording there changes the day the status does. For a security questionnaire or our one-page summary, email security@onky.ai.

Every action is logged at the OS level: who did what, when, with which model, touching which data. When auditors or regulators ask how an automated decision was made, your audit trail is the evidence: complete, queryable, and produced by the architecture itself rather than reconstructed after the fact.

Shadow operations occur when AI calls are made outside of governed channels. In this platform, every model call, build, and deployment is logged by the Kernel, our policy engine. All connectors are governed by default via MCP, ensuring that AI operates strictly within Kernel-enforced policies and full auditability.

The company brain is the structured map Onky builds from employee chats and your connected systems: processes, roles and ownership, handoffs, tools, and the know-how that lives in people's heads and usually leaves when they do. Access to it is governed by the Kernel, our policy engine, like everything else: role-based access, full audit trail, retention and deletion under your control. It is what lets Onky's agents and workflows act with context instead of guesses.

Onky finds the procedures that stall on one person or one inbox, then builds AI that runs them, with an audit trail. A SaaS workspace is a static collection of tools you administer; Onky is a governed operating layer for your organisation: the Kernel, our policy engine, runs every model call, build, and deployment through your policies and logs them end to end, connecting to core systems like SAP or Salesforce. Control and audit are part of the architecture, not bolted on afterward.

Yes, within your governance boundary. Your team can build the internal tools, agents, and workflows your organisation actually needs. Each one is registered with the Kernel, our policy engine, then policy-checked and audited before it can run, so new capability never arrives as ungoverned surface area. You extend what the system does without loosening who controls it.

Your team connects existing tools and systems through the Model Context Protocol (MCP). The Kernel, our policy engine, registers each connection as a governed System Driver: it is policy-checked and audited like everything else, then made available only to the workflows and agents allowed to use it. Integrating a tool never creates an ungoverned path into your data.

Every new tool, whether your team builds it or the Kernel, our policy engine, synthesizes it, goes through governed capability registration: it is indexed, policy-checked, and audited before it becomes part of the system. The platform gains capabilities with every task it executes, without gaining ungoverned surface area. Nothing joins the system outside the Kernel's control.

It finishes the job instead of failing it. When a request needs a tool that doesn't exist yet, the Kernel, our policy engine, saves the task with its full context, tells the requester which part is missing, and builds the missing tool. Once that tool has passed policy checks and capability registration, the original task resumes and completes. Every gap closed this way becomes a governed capability the rest of the organisation can reuse.

Yes. Every workflow and agent Onky builds carries an agent graph: a visual map of every step, decision point, data source, and action it can take. Admins review the graph before approving anything for use, it shows progress while a run executes, and afterwards it doubles as the audit record of what actually happened. Approval is never a black box: what you sign off is the same graph the run is held to by the Kernel, our policy engine.