AI governance
Governance is a product question, not a policy question.
Our agents read from and write to the systems you already run. This page explains who is accountable, what our agents can and cannot do, where humans sit in the process, and how every action an agent takes is recorded and can be inspected.
Last updated: August 11th, 2026 · Applies to the Company Brain, AI Assistants, AI Agents, and the node builder
01 · Our governance principles
Six rules we do not bend on.
Accountability is owned, not distributed.
A designated owner in our leadership is accountable for AI governance at Growy. Responsibility does not dissolve into "the team".
The client sets the boundaries.
Agents do what the organisation configures them to do. We do not decide on a client's behalf where a human belongs in a workflow. We make sure that decision is made deliberately and written down.
Everything is traceable.
Every workflow run and every node inside it is logged. If an agent did something, there is a record of what it did, when, and what it produced.
Nothing is a black box.
Agents are built from steps you can see. There is no hidden layer deciding outcomes off the record.
Autonomy is agreed, not assumed.
Agents are deployed at a level of independence the client chooses. That level widens only when the workflow has proven itself and the client agrees to widen it.
We are honest about limits.
AI gets things wrong. Governance exists because of that, not in spite of it.
02 · Who is accountable
Governance is owned, not shared into the void.
AI governance at Growy is owned at leadership level by a designated owner, who is accountable for:
- the models and providers we use, and the terms we hold them to
- the platform controls that make oversight possible: approvals, thresholds, escalation, pausing, logging
- reviewing AI systems, outputs and incidents, and acting on what those reviews show
- maintaining internal documentation of AI capabilities, limitations and data flows
AI governance is reviewed periodically, and after any significant incident or material change to the platform or the models underneath it. The individual holding this responsibility can be identified to clients on request.
Concerns can be raised at any time at [email protected].
03 · What our AI actually is
Two kinds of AI. One boundary: your systems.
Both operate only on the knowledge and integrations you provide. Neither reaches outside your account.
AI Assistants
Chat-based. They answer questions and surface information from your documents, manuals and connected tools. They advise. They do not act.
AI Agents
They execute. They run multi-step workflows across your systems, processing requests, generating reports, updating records and coordinating between departments, inside the boundaries you define in the node builder.
Agents act through your existing systems, using the connections you authorise and inheriting the role-based permissions already configured there. An agent cannot see or do something a properly permissioned user in that system could not. Actions are recorded in the source system as well as in Growy.
04 · Levels of autonomy
Not every workflow needs the same amount of human involvement.
Every Growy agent is deployed at one of three levels, agreed with the client and documented when the workflow is built.
Assistive
The agent prepares, drafts, analyses or recommends. A person decides and acts. Nothing changes in a live system without a human doing it.
Supervised execution
The agent runs the workflow, but designated steps require explicit human approval before it continues. Approval steps sit wherever the client places them: before an external message is sent, before a record is written, before a threshold is crossed.
Delegated execution
The agent completes the workflow within pre-agreed limits and reports what it did. This is used for repeatable, reversible, low-consequence operations. Anything outside the agreed limits triggers an escalation to a person rather than a decision by the agent.
Two rules apply at every level
- Actions that are irreversible, externally binding, financially material, or that determine an outcome for an individual are not delegated to an agent. They sit behind human approval.
- Any agent can be paused, modified or switched off at any time by the client.
Confidence thresholds sit underneath this. Where an agent's certainty on a step falls below the configured threshold, it does not proceed and guess. It escalates.
05 · Models and providers
We do not train our own foundation models. We hold the ones we use to our terms.
We use large language models from established providers: currently Anthropic, OpenAI and Google, and select the model per task on capability, reliability and cost. When your data is sent to a provider:
- it is sent solely to generate a response or complete a task inside your account
- it is covered by data processing terms that prohibit training on customer data
- providers are contractually barred from retaining or reusing it beyond fulfilling the request
- transmission is encrypted
We review our providers' security, privacy and compliance posture on an ongoing basis, and may change or add providers over time. Material changes to how client data is processed are communicated to affected clients.
We do not use your company data to train, fine-tune or improve any general-purpose model, and we do not share it with other customers.
06 · Traceability and audit
Every agent run is logged at two levels.
This is what makes governance real rather than declared. An agent's behaviour can be reconstructed from start to finish: to debug a failure, to investigate an unexpected output, to show an auditor what happened, or to improve the workflow.
Workflow level
What triggered the run, when, what path it took, and how it ended.
Node level
Each individual step: what went in, what came out, which system was touched, whether a threshold or approval was involved, and where the run stopped if it stopped.
Access to logs and outputs is controlled by role-based permissions. Retention follows the periods set out in our Privacy Policy.
07 · How agents are built and released
Governance is applied when the agent is built, not added afterwards.
Define the bottleneck.
We agree what the agent is for and, explicitly, what it is not for.
Map the workflow.
Systems, knowledge sources, edge cases, and human decision points. This is where the autonomy level is set and approval steps are placed.
Build and test in an isolated environment.
The agent is tested against real data before it touches live systems, until its behaviour is understood.
Client sign-off.
The client reviews the tested behaviour and approves deployment. No agent goes live on our judgement alone.
Deploy and monitor.
Outputs and performance are monitored after release, and workflows are refined based on what the logs show.
08 · Risk classification
Risk does not sit in the platform. It sits in the use case.
Growy is a general-purpose platform. Before deployment, each agent is assessed with the client against the risk categories in the EU AI Act (Regulation (EU) 2024/1689). Most Growy deployments: internal reporting, operational coordination, document retrieval, administrative workflow: fall within the minimal and limited risk categories.
Some use cases need more care. Workflows touching recruitment, evaluation, task allocation or other employment and worker-management decisions can fall within Annex III of the Act. Where a use case is in or near that territory, we say so, we design the workflow so that determinations about individuals remain human decisions, and we support the client, who is the deployer of the system in their own organisation, with the obligations that follow.
We do not build agents for biometric identification, social scoring, emotion inference in workplaces or education, or any practice prohibited under Article 5 of the Act.
Where a person is interacting with an AI system, that is disclosed, in line with Article 50.
Our full position on the AI Act and GDPR
Set out in full on the GDPR & EU AI Act page.
09 · Accuracy, limits, and what happens when something goes wrong
AI gets things wrong. We say so plainly.
AI outputs may be inaccurate, incomplete or out of date. Models can misread correct inputs, apply logic incorrectly, produce confident and wrong answers, and reflect bias present in their training data. A model does not understand in the human sense. It produces statistically likely output. We say this plainly because trust is built on honesty rather than on overpromising.
What we do about it
- Grounding. Assistants and Agents answer from your knowledge base and connected systems rather than open-ended model recall, which materially reduces fabrication.
- Thresholds and escalation. Low-confidence steps stop and escalate rather than proceed.
- Human checkpoints. Consequential steps sit behind approval.
- Full logs. When something goes wrong, we can see exactly where.
- Correction. Issues are addressed through workflow changes, instruction adjustments, model selection changes or additional safeguards, and the fix is verified against the case that surfaced it.
If you believe an agent has produced an incorrect, unfair or harmful output, report it to [email protected]. Reported issues are investigated against the logs for that run.
10 · What we ask of you
Governance is shared.
Working with Growy, you are responsible for:
- deciding where human approval is required in your workflows, and telling us
- ensuring the data and documents you upload are accurate and lawful for you to use
- reviewing AI outputs before relying on them for consequential decisions
- keeping permissions in your connected systems current, since agents inherit them
- telling us when a workflow's purpose changes, so its risk classification can be reassessed
12 · Contact
Questions about how this works? Ask directly.
We may update this page as the platform, our providers, or the regulatory landscape change. The current version is always shown by the date at the top.