The EU AI Act and John CEO: building an AI coworker for Europe's rules

Picture a new colleague in your company Slack. At 7:42 on a Monday it has already answered three questions, drafted the client update, and suggested a time for the follow-up call. It is polite, on topic, and fast. Would everyone who talks to it know it is not a person?

If that colleague is an AI, European law now has an opinion about it. Since 2 August 2026, Article 50 of the EU AI Act requires that people be told when they are interacting with an AI system. An AI coworker that drafts email, answers in Slack, and works inside your business tools is exactly the kind of product that rule was written for.

John CEO is built by JHELY GLOBAL SL, a company incorporated in Malaga, Spain. We did not have the option of treating European rules as someone else's problem. This article explains what those rules actually say, and the technical, legal, and process decisions we made so that John fits them by design rather than by patch.

The EU rulebook in plain words

Three pieces of law shape how an AI coworker can work in Europe.

The AI Act (Regulation (EU) 2024/1689). The world's first broad AI law sorts AI systems by risk. A short list of practices is banned outright. "High-risk" systems, such as AI used to screen job candidates, score credit, or run critical infrastructure, carry heavy obligations: risk management, documentation, human oversight, and registration. A middle tier of systems that talk to people or generate content carries transparency duties. Everything else is largely left alone.

The Act arrives in stages:

The last two dates are new. In July 2026 the EU adopted the "Digital Omnibus on AI" (Regulation (EU) 2026/1744), which entered into force on 27 July 2026. It pushed the high-risk deadlines back, softened the AI literacy duty into an obligation to take measures that support the development of AI literacy, and gave providers of generative systems already on the market until 2 December 2026 for machine-readable marking of AI-generated content. What it did not delay is the core of Article 50: telling people they are dealing with AI.

The GDPR. Any AI coworker that reads your inbox processes personal data, often about people who never signed up for anything. The GDPR decides who is responsible for that data, where it may travel, and what rights people have over it.

Your own role. The AI Act separates the "provider" who builds a system from the "deployer" who uses it in their business. For John, we are the provider of the system and you, the customer, are the deployer inside your company. That split matters, and we come back to it below.

Where does John sit? John is a general business coworker: it drafts, summarises, schedules, and acts in tools you connect. That puts it squarely in the transparency tier. Our Terms of Service go one step further and forbid using John as part of a high-risk system, for example to make hiring, credit, insurance, or eligibility decisions about people without meaningful human review.

Decision 1: John is open about being AI

Transparency is the rule that applies to John most directly, so it is where we started.

• First contact says it plainly. When someone first talks to John in a Slack workspace, our platform posts a notice: "You are interacting with an AI system operated for" the account owner's name "through John CEO." The wording was reviewed by our legal advisers rather than improvised. In Telegram, John is instructed to open with an equivalent line.
• John never pretends to be human. Every workspace starts with standing instructions: never claim to be human, never remove or reword a line stating that a message was sent by an AI system, and if anyone asks, answer honestly that John is an AI coworker.

Our Terms also make the customer side explicit: you agree not to remove, hide, or instruct John to conceal these disclosures, and as the deployer you handle any extra transparency your own use requires, for example telling your staff how you use John internally.

Decision 2: one private workspace per customer

Most AI products run every customer in one shared system and separate them with software rules. We went the other way. Every John customer gets their own private workspace: a space set up just for you, with its own storage, not mixed with anyone else's.

• New workspaces are created in Germany. We host workspaces at Hetzner in Falkenstein. The application that coordinates workspaces runs in Ireland, and its database is hosted in the EU.
• We are honest about AI processing. New workspaces sit in Germany, but the AI model and routing you choose decide where the thinking happens. Some model providers process requests outside the European Economic Area, and so do a few of our service partners. Our Privacy Policy says so directly, uses the European Commission's Standard Contractual Clauses where needed, and treats your choice of model as your documented instruction. We would rather tell you that than promise "your data never leaves the EU" and quietly bend the truth.
• Platform secrets never reach your workspace. This is one of the few rules our engineering handbook calls a "law": no platform secret ever lands on a customer workspace. The only sensitive items that reach it belong to your account: a separate AI spend key, your optional Telegram chat connection, access passes that work only for your own workspace, and a one-time setup code that is stored only as a fingerprint, works once, and expires within an hour. Access to your connected apps goes through our side, so our app partner's main login never sits next to your data.
• Stored logins are encrypted. Your AI spend key and the logins for the channels you connect, such as Slack and Telegram, are encrypted with AES-256-GCM, and the key that protects them stays on our side, never on a workspace. Logins for your connected apps are held by our app partner and are never placed on your workspace.

Isolation is not a legal requirement on its own. But the GDPR asks for security "appropriate to the risk", and it is far easier to reason about one customer's data when it physically lives in one place.

Decision 3: humans approve the actions that matter

The AI Act's high-risk rules centre on human oversight. John is not a high-risk system, but we think the principle is right for anything that acts in your name.

• Reading is free, writing asks first. When John wants to use a connected app, each action is classified before it runs. Reading, searching, and reporting go straight through. Anything that writes, deletes, or sends something out stops and asks for approval in your chat. If we cannot tell what an action does, it is treated as a write. The system fails closed.
• You choose how much trust to grant. Approve once, approve for this conversation for about ten minutes, allow this kind of action for 30 days, or deny. A denial blocks that same action from simply being retried, so John has to change course.
• Approvals leave a tamper-evident trail. Approvals, denials, and connected-app actions are written to an action ledger in which each entry carries a cryptographic fingerprint of the one before it. Editing or removing an earlier entry breaks the chain. The ledger also refuses to store fields that look like passwords or secret keys.

Our Terms describe the same model in contract language: low-risk work runs directly, higher-risk actions may need explicit approval, and John does not move money on your behalf.

Decision 4: less data by default

The best protection for personal data is not having it in the first place.

• No training on your conversations by default. We do not use your conversations, prompts, or John's replies to train or improve models unless you expressly opt in, and that option never applies to data from Slack.
• Some data is out of bounds. Our Terms prohibit using John for special-category data such as health or biometric data, payment card numbers, other people's passwords, and data about minors. This is enforced in software too: card numbers are detected and the action is blocked before it reaches a connected app, and John is instructed to politely decline tasks built around prohibited data.
• Analytics wait for consent. On our website and dashboard, analytics tools load only after you accept them in the cookie banner.
• Error reports are scrubbed. When something breaks, the reports our engineers see are configured not to include personal data, and a scrubber strips sensitive fields before they leave.

Decision 5: a legal setup that matches the architecture

Legal documents are only useful if they describe the system you actually run. Ours follow the same lines as the technology.

• Clear GDPR roles. For your account, billing, and settings, we are the controller. For the personal data John touches inside the tools you connect, you are the controller and we act as your processor, on your instructions. A data processing agreement under Article 28 GDPR is available on request.
• Named partners, in public. The companies that help us run John, from hosting to payments, are listed on our subprocessors page, with where they operate.
• A known regulator. As a Spanish company, our lead data protection authority is the Agencia Espanola de Proteccion de Datos (AEPD).
• The AI Act is written into the contract. Both our Privacy Policy and Terms of Service reference Article 50 by name, and our Terms define who the deployer is and rule out high-risk use.

Decision 6: process is part of compliance

Rules are kept or broken in everyday engineering work, not in policy documents. A few of the habits we built into how John is developed:

• Review depth scales with risk. Every change is graded from S0 (copy and docs) to S3 (code with many dependents). Anything beyond S0 needs a review by a fresh reviewer whose job is to break the change, not approve it. From S2 upward, a separate security review is required. Changes touching security, approvals, billing, data, or sign-in are automatically held to a higher minimum tier.
• Legal documents are frozen. Our Terms and Privacy Policy cannot be edited in passing. Any change needs explicit human approval of the exact wording, confirmed twice. No automated tool may touch them alone.
• Plans are written down before code. Larger changes start as an approved written plan stored with the code, so the reason behind each decision survives the people who made it.
• Production is a separate, gated step. Changes reach john.ceo only through a reviewed promotion from our development branch, never by pushing straight to production.

What this means for you

If you use John in your business, the AI Act calls you the deployer, and a few things are worth doing:

1. Tell your team. Let colleagues know John is an AI coworker and what it handles. That is both good practice and the spirit of the Act's AI literacy duty.
2. Do not hide that it is AI. Our Terms forbid removing or concealing AI disclosures. Treat them as a feature: people trust a clearly labelled assistant more than a suspicious one.
3. Choose your model on purpose. Your model choice affects where AI processing happens. If keeping it inside the EEA matters to you, take that into account and ask us for details.
4. Keep humans on decisions about people. Use John to prepare, draft, and summarise. Keep hiring, credit, and similar judgments with a person.
5. Ask for paperwork when you need it. If you need a data processing agreement, write to [email protected].

Europe's approach to AI is sometimes described as a brake on innovation. Building John, we found the opposite. Most of the rules describe things a careful team would want anyway: tell people the truth, keep data where you said it would be, let humans approve what matters, and write down why. The law simply made us do it from day one.

This article describes how John CEO is designed and is not legal advice. For your own obligations, speak to a qualified adviser. Sources: Regulation (EU) 2024/1689, Regulation (EU) 2026/1744, and the European Commission's AI Act implementation timeline.