Digital Employee is designed with privacy, security, human oversight and responsible AI governance at its core. Our approach supports an assessment of the frameworks applicable to each project, without confusing technical readiness with automatic compliance or certification already awarded.
Governance comes before production
A Digital Employee receives an assignment, not unlimited authority. Before it is connected to business systems, the project needs to establish which tasks it may carry out, which data it needs, who approves sensitive actions and who handles exceptions. Privacy, security and human oversight belong in the design, rather than in a note added at the end.
Our approach is designed to support organisations operating across multiple jurisdictions. This does not mean every configuration automatically complies with every law. The scope must be assessed against the actual use case, with the process owner, IT and the appropriate privacy and legal specialists.
GDPR: start with data and responsibilities
The GDPR governs the protection of personal data. Privacy-conscious architecture can support a compliant deployment, but it does not replace an assessment of the processing. Questions to resolve include purpose, lawful basis, responsibilities, data minimisation, access, retention, the providers involved and the handling of individuals’ rights. Reference: European Commission.
Data storage location must be distinguished from where data is processed or accessed. Before release, the full flow needs to be understood: applications, AI models, activity logs, support and subprocessors. Processing agreements, international transfers and impact assessments must be considered where applicable. A European data centre alone does not answer all these questions.
EU AI Act: assess the use case, not just the technology
The European framework for AI takes a risk-based approach. Applicable obligations also depend on the intended use and the organisation’s role. A model name or the label “Digital Employee” is not enough to determine the scope. Reference: European Commission, AI Act.
The assessment needs to establish the purpose, the people affected, potential consequences and the oversight required. Transparency, documentation, risk management and human controls should be defined in relation to the applicable requirements. A process that prepares a draft should not automatically be treated as equivalent to one that makes decisions about people.
NIST AI RMF: organise AI risk management
The NIST AI Risk Management Framework is a voluntary reference for incorporating trustworthiness into the design, development, use and evaluation of AI. It is not a product certification. Our governance practices are aligned with internationally recognised principles for trustworthy and responsible AI risk management. Reference: NIST.
In practical terms, this means assigning responsibilities, understanding the context, checking outcomes and managing the risks identified. The project should also establish how to report an incident, pause an activity and review controls when tools, data or the assignment change.
Canada: establish which rules actually apply
Our approach is designed to support deployments subject to applicable Canadian privacy requirements, including PIPEDA where relevant. The framework may also include provincial legislation and sector-specific rules: there is no single “Canada compliant” label that covers every project. Reference: Office of the Privacy Commissioner of Canada.
Purpose, consent where required, limited collection, retention, safeguards and supplier accountability need to be considered in the organisation’s context. Data flows across provincial or national borders also require attention.
ISO/IEC 42001: distinguish the standard from certification
ISO/IEC 42001:2023 concerns an organisation’s Artificial Intelligence Management System. It is not a blanket guarantee that every individual use of a product complies with all applicable requirements. Reference: ISO.
Our underlying AI technology provider is currently progressing towards certification of its management system. This reference does not state that certification has already been awarded, or that Digital Employee or ESD is certified. Any eventual certificate should be checked for the legal entity, scope, issuing body and validity; it does not automatically extend to the customer or their deployment.
The controls to agree for your process
Before production, the project should make six elements verifiable: the assignment and its boundaries; authorised systems and data; actions requiring approval; records of relevant activity; exception handling and stopping conditions; and responsibilities and review arrangements. The availability and detail of controls depend on the agreed solution and integrations.
For example, a Digital Employee might prepare a comparison between invoices and purchase orders. The project could require discrepancies to remain open for the team’s review and payment authorisation to stay separate. This is an illustrative process to assess, not a promise that these controls are already active in every configuration.
Move from statements to evidence
Start with a specific process and ask which data it touches, which decisions it prepares or executes and which evidence makes it possible to check the work. Our Security & Governance page summarises the approach. The guides to permissions and approvals and supplier assessment help you prepare the right questions before a demo.
This guide describes our approach and the reference frameworks. It is not legal advice, a certification or a guarantee of compliance. The assessment must be completed for the specific use case.