1.1 Terms
The Terms define rules for accounts, workspaces, AI-assisted work, customer apps, acceptable use, access, service changes, support, and responsibility boundaries.
COMPLIANCE CENTER
Atom9 builds compliance into the workflow.
Atom9 is built for companies that need websites, login, workflows, content, automation, customer data, and AI help without losing control of privacy, security, approvals, legal duties, or evidence.
Compliance principle
Atom9 follows applicable privacy, security, consumer, AI, and sector compliance duties through product controls, documented roles, approval gates, audit trails, and clear customer responsibilities.
Compliance 1
Each legal page answers a different compliance question.
Document mapStart from the question, then use the matching legal page.
Can we use it?TermsRules, responsibility, acceptable use, AI work, and customer apps.
What data?Privacy and GDPRData categories, purposes, roles, processors, rights, and transfers.
What runs in browser?CookiesRequired storage, optional choices, third parties, and customer-site notices.
What is safe?SecurityAccounts, roles, product surfaces, AI prompt safety, integrations, and reporting.
What must keep running?DORAFinancial-sector ICT risk, incidents, resilience testing, provider risk, and evidence.
Legal anchors: Compliance 1.1 to 1.6 map the documents and Compliance 3 defines the product controls used across them.
1.2 Privacy
The Privacy notice explains what data Atom9 handles, why it is used, how AI uses context, how data is shared, and how people exercise rights.
1.3 GDPR roles
The GDPR page defines when Atom9 is controller, processor, or using sub-processors, and how customer apps fit into that responsibility chain.
1.4 Cookies
The Cookie Policy separates required session and security storage from optional preference, analytics, third-party, and customer-site storage.
1.5 Security
The Security page explains approved product surfaces, account responsibilities, workspace safety, customer-app launch security, AI prompt safety, integration care, and reporting paths without exposing internal architecture.
1.6 DORA
The DORA page explains financial-sector digital operational resilience alignment for ICT risk, incidents, resilience testing, third-party provider risk, continuity, and evidence.
Compliance 2
Atom9 can be the product, the login layer, and the builder of customer software.
2.1 Person
A person creates an Atom9 account, signs in with an approved login method, manages account security, and accesses workspaces or customer apps where the person has access.
2.2 Company workspace
A workspace owns projects, team access, content, contacts, files, approvals, billing references, connected tools, and customer-app configuration.
2.3 AI agent
An AI agent uses approved project context and connected tools to draft, build, inspect, explain, and record work according to workspace settings.
2.4 Customer app
A customer app uses Atom9 infrastructure while keeping its own customer relationship, notices, service-specific KYC, and lawful basis decisions.
Compliance 3
Compliance controls are visible during work, not hidden until launch.
3.1 Approval gates
Approval gates require clear human decisions before plans, AI-generated outputs, launch checks, sensitive workflow changes, and regulated use cases become live.
3.2 Data minimisation
Atom9 follows data minimisation by asking for the data needed to run the account, workspace, and customer app. Extra customer KYC belongs to the customer app flow.
3.3 Audit history
Atom9 saves important decisions, approvals, prompts, generated assets, tool actions, provider settings, and launch checks as an evidence trail with enough context to explain them later.
3.4 Security by default
Email verification, OIDC linking confirmation, passkeys, session controls, role boundaries, service authentication, permission checks, and provider controls are baseline product controls.
3.5 Risk escalation
High-risk sectors, regulated workflows, special data categories, child data, financial data, health data, and unusual data requests trigger stronger setup, approval, and compliance review paths.
Compliance 4
Atom9 treats the EU AI Act as a product-design requirement.
AI risk ladderRisk determines the controls before a workflow can launch.
BlockedProhibited useManipulation, social scoring, prohibited biometric use, and other banned practices.
Strict gatesHigh-risk useRisk assessment, data governance, logging, documentation, oversight, robustness, and launch approval.
DisclosureTransparency riskAI chat, generated content, model/provider identity, and user-facing disclosures.
BaselineMinimal riskNormal product controls, security, auditability, and user clarity.
Legal anchors: Compliance 4.5 blocks prohibited practices, Compliance 4.7 handles high-risk workflows, and Compliance 4.2 covers transparency.
4.1 AI literacy
Atom9 explains agent behaviour in practical terms and shows users what the agent is doing, what it needs, what it changed, what tools it used, and what the person must approve.
4.2 Transparency
Atom9 makes AI chat, AI-generated content, tool use, model/provider identity, and relevant automated actions visible in the product history where the workflow requires accountability.
4.3 Human oversight
Atom9 keeps important project, launch, customer-facing, and regulated changes under human oversight instead of silent automation.
4.4 Risk classification
Atom9 uses risk classification to route sensitive sectors, high-impact use cases, regulated decisions, and unusual data requests into stronger questions, model/provider checks, evidence trails, and approval steps.
4.5 Prohibited practices
Atom9 does not support workflows designed for unlawful manipulation, unlawful discrimination, social scoring, prohibited biometric use, illegal profiling, or other uses prohibited by applicable AI, privacy, consumer, or sector law.
4.6 Records and logging
Atom9 records AI provider, model identity, tool access, data settings, prompts, outputs, approvals, tests, and relevant decisions where the workflow requires accountability.
4.7 High-risk handling
Atom9 requires stronger documentation, human oversight, test evidence, data governance review, incident escalation, and launch approval before a high-risk or regulated AI workflow can be treated as ready.
- The customer use case is classified before launch when the project appears regulated, high-impact, or sensitive.
- Human oversight, test evidence, data governance, and logging are documented before the workflow is approved.
- Serious defects, incidents, or unsafe behaviour are escalated through the incident and launch review process.
4.8 Provider and deployer boundaries
Atom9 documents whether Atom9, the customer, or an external model provider is acting as provider, deployer, processor, or sub-processor for an AI workflow and records the resulting responsibilities.
Compliance 5
Atom9 designs deployment choices around control, locality, and accountability.
5.1 Data residency
Atom9 supports customer decisions about where data is stored and processed, including EU-focused deployments where residency is required.
5.2 Operational autonomy
Atom9 separates product operation, provider access, support access, customer configuration, and service credentials so operational control can be documented and limited.
5.3 Provider boundaries
Atom9 documents infrastructure, file storage, search, email, AI, observability, payment, and support providers so customers understand which systems support their service.
5.4 Transfer safeguards
Atom9 uses lawful transfer mechanisms, transfer risk review, contractual controls, and provider settings when personal data is processed outside the EU/EEA.
Compliance 6
Customers remain responsible for the services they operate.
6.1 Service purpose
The customer defines what the customer app does, what data it needs, who may use it, and what laws apply to the service.
6.2 Customer notices
The customer approves customer-facing privacy notices, cookie notices, terms, consent text, KYC wording, AI disclosures, and sector-specific disclosures before launch.
6.3 Data quality
The customer is responsible for the accuracy, lawfulness, and relevance of data they enter, import, request, or instruct Atom9 to process.
6.4 Access management
The customer controls team invitations, roles, offboarding, project access, and who may approve sensitive actions.
6.5 Regulated use
The customer must identify regulated duties such as finance, health, employment, children, consumer protection, professional advice, accessibility, or public-sector requirements.
Compliance 7
Atom9 keeps records needed to explain what happened.
Evidence trailThe useful record connects the user decision to the system change.
ChatQuestion and answerWhy the project or change exists.
AtomSpec or planThe readable decision document.
ApprovalHuman decisionApproved, rejected, or changed.
ActionTool resultWhat changed in files, workflow, data, or provider.
LaunchFinal checkPrivacy, cookie, AI, security, and sector review.
Legal anchors: Compliance 7.1 to 7.4 define the records kept for chats, approvals, tool actions, and launch checks.
7.1 Chats and prompts
Important agent conversations, clarification questions, user answers, prompt context, and generated summaries stay connected to the project.
7.2 Approvals
Approval gates record what was approved, who approved it, when it was approved, and what decision created the next project state.
- The approval record identifies the approved object, version, and project context.
- The approval record stores the user's decision and any change request text.
- The approval record links to the chat, atom, task, or launch check that created the decision.
7.3 Tool actions
Tool invocations, generated content, file changes, workflow changes, and connected provider actions are logged where relevant.
7.4 Launch checks
Privacy, cookie, AI, security, accessibility, and sector checks stay visible before a customer app goes live.
7.5 Legal updates
Atom9 updates product controls, docs, notices, and customer guidance when legal, provider, security, or operational requirements materially change.
Compliance 8
Framework tags show which duties a statement supports.
Framework synergyOne control can satisfy several obligations when the evidence is clear.
Personal dataGDPRPurpose, roles, rights, retention, processors, transfers.
AI workEU AI ActRisk, transparency, human oversight, data governance, logs.
Financial resilienceDORAICT risk, incidents, testing, continuity, provider risk.
CybersecurityNIS2 and securityRisk analysis, incident handling, continuity, supply chain.
CommitmentsContractsDPA, service levels, support scope, stricter customer terms.
Legal anchors: Compliance 8.1 to 8.6 define how tags are used. Tags are traceability labels, not certification marks.
8.1 Privacy tags
GDPR and privacy tags identify statements that support data roles, lawful basis, minimisation, retention, subject rights, processors, transfer safeguards, cookie choices, or customer-app notices.
8.2 AI tags
EU AI Act tags identify statements that support AI literacy, transparency, human oversight, risk classification, prohibited-use blocking, high-risk handling, logging, and provider or deployer boundaries.
8.3 DORA tags
DORA tags identify financial-sector operational resilience statements that support ICT risk management, incident handling, resilience testing, third-party ICT risk, continuity, and evidence.
8.4 Cybersecurity tags
NIS2 and security tags identify statements that support account protection, risk analysis, incident handling, business continuity, supply-chain care, vulnerability handling, and secure operation.
8.5 Contract and operation tags
Contract and operation tags identify statements that may be tightened by signed customer terms, DPAs, security addenda, service levels, support paths, provider terms, or customer-specific operating requirements.
8.6 Shared evidence
Atom9 should reuse the same approval record, data-source policy, incident record, provider review, launch check, and change history across frameworks when the same fact supports more than one duty.
Compliance 9
GDPR and DORA are not enough for the full Atom9 legal set.
9.1 AI governance page
Atom9 needs a dedicated AI governance and EU AI Act page covering AI literacy, transparency, provider and deployer roles, high-risk screening, prohibited use, human oversight, model/provider records, incidents, and customer-app AI disclosures.
9.2 NIS2 and cyber resilience page
Atom9 needs a NIS2/cybersecurity page that explains cybersecurity risk management, incident handling, business continuity, supply-chain care, vulnerability handling, access control, and the public security rules customers must follow.
9.3 Sub-processors and transfers page
Atom9 needs a public sub-processor, provider, and transfer page showing service-provider categories, data locations where available, transfer safeguards, customer notice rules, provider change notice, and how customers request more detail.
9.4 Vulnerability disclosure page
Atom9 needs a public vulnerability disclosure page that explains allowed reporting, prohibited testing, safe evidence, response expectations, and the line between good-faith reporting and unauthorised security testing.
9.5 Accessibility page
Atom9 needs an accessibility statement covering product accessibility, customer-app accessibility responsibilities, assistive-technology support, known limitations, feedback channels, European Accessibility Act screening, and how accessibility checks are included in launch review.
9.6 Customer contract artifacts
Atom9 also needs maintained customer-specific artifacts: data processing agreement, security addendum, service levels, order forms, incident contact process, sub-processor notice process, and regulated-sector addenda where a customer use case requires them.
9.7 Data Act, CRA, and DSA screening
Atom9 should add screening notes for the Data Act, Cyber Resilience Act, and Digital Services Act. These do not apply equally to every Atom9 customer app, but the agent should identify when cloud switching, products with digital elements, user-generated content, marketplaces, hosting, or platform moderation duties become relevant.
9.8 Agent intake requirement
The Atom9 project agent must ask enough questions to identify whether a project touches AI, personal data, financial-sector services, cybersecurity-sensitive workflows, accessibility obligations, provider outsourcing, user-generated content, or regulated customer KYC before committing to a build plan.
Compliance 10
Atom9 flags work by explaining the reason, severity, owner, and next action.
The item has a clear purpose, enough evidence, a known owner, safe defaults, and no unresolved compliance or security blocker.
- Can continue.
- Keep normal audit record.
- Review again when scope changes.
The item may be acceptable, but a person must confirm missing context, legal basis, customer wording, provider use, or launch intent.
- Pause the specific step.
- Ask the owner a focused question.
- Continue only after recorded decision.
The item touches sensitive data, regulated work, important provider dependency, high-impact decisions, or a customer-facing launch path.
- Require stronger review.
- Collect test and approval evidence.
- Escalate if scope is unclear.
The item is unsafe, unlawful, deceptive, unsupported, missing required authority, or trying to bypass a product or security control.
- Stop the action.
- Record the reason.
- Offer a safe alternative where possible.
10.1 Decision inputs
Atom9 grades work using the service purpose, data sensitivity, people impact, legal framework, provider dependency, security posture, evidence quality, and whether the user-facing explanation is clear.
10.2 Good signals
Good signals include clear service purpose, data minimisation, verified domain, least-privilege roles, transparent notices, required approvals, passing launch checks, recorded provider use, and no restricted data outside configured scope.
10.3 Review signals
Review signals include unclear owner, unclear lawful basis, new provider use, cross-border transfer, optional tracking, AI-generated customer-facing wording, ambiguous KYC, missing test evidence, or a customer notice that is not ready.
10.4 High-risk signals
High-risk signals include special-category data, financial data, health data, child data, employment decisions, critical or important functions, automated high-impact decisions, public launch, and external providers with sensitive access.
10.5 Block signals
Block signals include prohibited AI use, no lawful basis, missing authority, exposed secrets, unverified production domains, unsupported internal routes, bypassing approval gates, deceptive notices, malware, stolen data, or attempts to access another person's data.
10.6 Required decision record
Each important flag should record the grade, reasons, affected project or workflow, owner, next action, evidence required, due date where useful, and whether the agent may continue, must ask a question, or must stop.
10.7 Agent behaviour
The agent should explain flags in chat, show the exact reason, ask only the missing question, create an approval gate when a person must decide, and connect the final decision to the project history.
10.8 Re-grading
A good item must be re-graded when scope changes: new data fields, new provider, new country, new user group, AI automation, public launch, regulated purpose, or a material change to how the service works.