FAQ: add "Artificial Intelligence and AI agents" section (6 questions)

[tyche-dev]

What this adds

A new FAQ section, "Artificial Intelligence and AI agents", with six
questions. The FAQ currently has no coverage of AI, AI agents, or the CRA's
interaction with the AI Act, even though much of the open-source ecosystem now
ships and depends on AI components. These questions come up repeatedly, so this
section collects them in one place.

Questions added

1. Does the CRA apply to AI systems and AI agents? (no AI carve-out; scope turns on the product-with-digital-elements definition and the data-connection trigger — Art 2(1), 3(1))
2. My software embeds an AI model or LLM — is it a product with digital elements? (yes; server-side inference as remote data processing — Art 3(2))
3. Is a hosted AI agent or MCP-style tool server in scope, or an out-of-scope cloud service? (fact-specific; Recital 12 cloud line; NIS2 boundary — flagged as benefiting from EC guidance)
4. My product is also a high-risk AI system under the AI Act — do I need two conformity assessments? (Art 12 presumption; single AI Act Art 43 assessment; Art 12(3) important/critical derogation)
5. What does the CRA require me to log for an AI system, and must the logs be tamper-proof? (Annex I Part I (2)(l); the honest point that log integrity is not prescribed)
6. I maintain an open-source AI-agent framework but do not monetise it — am I in scope? (Recital 18; steward regime Art 3(14)/Art 24; fines exemption Art 64(10)(b))

Notes for reviewers

• All six answers are marked ⚠️ Draft and cite primary CRA / AI Act
  provisions in the Source: front-matter. Every article, recital and quotation
  was checked against the Official Journal texts of Regulation (EU) 2024/2847
  (CRA) and Regulation (EU) 2024/1689 (AI Act).
• Question 3 (hosted agent vs cloud service) is marked as one that would benefit
  from European Commission guidance — the remote-data-processing / NIS2 boundary
  is genuinely fact-specific.
• Happy to split this into per-question issues/PRs if the maintainers prefer, and
  to adjust placement of the section in faq.md and faq/README.yml.
• Cross-links use existing pages ([[scope]], [[out-of-scope]],
  [[remote-processing]], [[monetisation]], [[profit]],
  [[what-is-a-steward]], [[inheriting-product-classification]]); please flag
  any slug mismatches.

Contributed on behalf of Tyche Institute (Tallinn, Estonia), a non-profit
research association working on AI governance, evidence, and auditability.

[tobie]

Plan is to discuss this PR in the next FAQ TF call (proposed agenda).

[tyche-dev]

Heads-up ahead of tomorrow's TF call: I'm at the ENFIELD final conference in Brussels on 7–8 July, and the call overlaps a session I can't move, so I'll most likely have to miss it. Please don't hold the discussion up on my account — I'll pick up this thread and any review comments right after July 8 and can turn edits around quickly.

In case it helps the discussion, my position in brief: I'd keep the section as a single PR, since the six answers cross-reference each other and are meant to read as one unit. If the TF prefers incremental merges, the natural cut is to peel off the hosted-agent / cloud question (the one flagged for EC guidance) into a follow-up PR and land the other five first.

Housekeeping: the ECA is signed and the commit carries a DCO sign-off; if the validation bot still flags the commit email, I'll sort out the account linkage right after the conference.

[tyche-dev]

Hi Tobie — following up on this PR. I had to miss the 7 July slot (I was at the ENFIELD final conference), and I see the FAQ TF calls have been paused over the summer since. I'd like to pick #353 back up at the next call — 18 August, by my reading of the ORC calendar.

It's ready for review: six Draft answers, each citing primary CRA / AI Act provisions; the ECA is signed and the commit carries a DCO sign-off. Happy to walk through it live, take edits, or split off the hosted-agent / cloud question (the one flagged for EC guidance) into a follow-up PR so the other five can land first — whichever the TF prefers.

If it would help to have it on the agenda, could you slot it when you draft the 18 Aug call? And if I've misread the schedule, just point me at the right date. Thanks!

[eeee2345]

On (2)(l): the answer says relevant internal activity "plausibly includes the actions it takes and the tools it calls" — for an agent that word is load-bearing, because (2)(l)'s own examples ("access to or modification of data, services or functions") can be made concrete rather than left open-ended. The security-relevant events for an AI agent are enumerable: tool/function calls and their arguments, the content returned by tools and retrieval (a primary channel for injection), reads and writes against memory or context, and requests that cross a trust boundary. That enumerability is the practical point for (2)(l): a logging requirement you cannot enumerate is one two vendors will implement very differently while both claiming conformity — a reason to pin the categories down in guidance or a harmonised standard. There's open, MIT-licensed prior art decomposing agent activity into event classes along these lines, with an explicit trust-boundary section: https://github.com/Agent-Threat-Rule/agent-threat-rules/blob/main/SPEC.md

On the "independently verifiable" point you flag: (2)(l) plainly doesn't reach the integrity of the record itself. Whether (2)(f) already does is the genuinely unsettled part — its integrity duty runs to "stored ... or otherwise processed data," and a security log is processed data, yet the text neither singles the log out nor excludes it. It matters in practice: a self-attested log the agent can write to itself is within reach of anyone who has taken over the agent's actions — unless the record is anchored outside the agent's own write boundary (tamper-evident anchoring, an issuer signature, an external witness). That's exactly the ambiguity a FAQ or standard could resolve.

@tyche-dev @tobie

[KentChenY]

probe: fetch comments list for issue 353

[tyche-dev]

Thank you — both points land, and I would rather adopt them than defend the draft.

On (2)(l) and enumerability. Agreed, and I think you have identified the actual weakness in our wording. "Plausibly includes" was doing the work of a hedge where a list would do the work of an answer. The event classes you name — tool and function calls with their arguments, content returned by tools and retrieval, reads and writes against memory or context, and requests crossing a trust boundary — are descriptive of what an agent does rather than prescriptive of what a manufacturer must do, which is what lets them sit in a FAQ answer without turning it into guidance the FAQ has no standing to give.

Proposed change to Q5: replace the hedge with that list, marked explicitly as illustrative and not exhaustive, and keep the flag that the category boundary would benefit from Commission guidance or a harmonised standard. Your framing of why it matters is the sentence worth keeping: a logging requirement nobody can enumerate is one two vendors will implement very differently while both claim conformity.

I checked the repository you cite before relying on it: MIT, an AgentEvent abstraction covering LLM I/O, tool calls and context-window state, an open event-class enum, and a trust-boundary section at 13.1. It is third-party work, not ours, and it is fair evidence that the decomposition is practicable rather than merely arguable.

On log integrity. Your reading of (2)(f) is better than what we drafted, and I would like to take it. We said the text is silent on whether the record itself must be protected; you sharpen that to the right question — (2)(f)'s integrity duty runs to "stored ... or otherwise processed data", a security log is processed data, and the text neither singles it out nor excludes it. That is a genuine ambiguity rather than a gap, and stating it that way is both more accurate and more useful to a reader.

The practical consequence you draw is the one I would keep verbatim in substance: a self-attested log the agent can write to itself is within reach of whoever has taken over the agent's actions.

One disclosure, since you raised the remedies. You mention anchoring outside the agent's write boundary, an issuer signature, an external witness. I work on exactly that as a research subject and have drafts in flight on it, so I am not a neutral party on whether those are the answer. I would rather the FAQ state the ambiguity and stop there than have it recommend a construction I happen to work on — a FAQ answer is not the place to seat anyone's preferred mechanism, mine included. If the task force wants to go further than stating the ambiguity, I am happy to contribute on the merits with that interest on the record.

Process note. The FAQ TF slot has now been cancelled four times running (7 and 21 July, 4 and 18 August — the 18 August occurrence is an EXDATE in the ORC calendar), and the next live one is 1 September. Rather than hold this open for another two weeks, I will push the Q5 revision and the (2)(f) rewording as commits on this branch this week, so the text is reviewable asynchronously. If anyone prefers to see them discussed first, say so and I will hold.

[eeee2345]

@tyche-dev — glad it's useful, and I think you're making the right call on all of it.

On the remedies: I'd go further and say the FAQ should not seat any mechanism, mine included. I listed anchoring, an issuer signature, and an external witness only to show the ambiguity has real consequences, not to argue for any one of them. "This is unsettled and here is why it matters" serves a reader better than a construction that looks settled and isn't.

On the taxonomy: the event-class enum lives in the versioned SPEC, so a Q5 citation can pin to a commit and won't move under you. Happy to answer anything on the merits, but you clearly have it — no need to hold the branch on my account.

[tyche-dev]

Both revisions are pushed, as flagged on 18 August — e156aa7 and 1941039, on Q5 (ai-logging-integrity.md), reviewable asynchronously ahead of the 1 September slot.

(2)(l). The hedge is gone, replaced by the event classes named in review — tool and function calls with their arguments, content returned by tools and retrieval, reads and writes against memory or context, requests crossing a trust boundary — marked illustrative and not exhaustive, and descriptive of what an agent does rather than prescriptive of what a manufacturer must record. The reason it matters is kept in the text: a requirement nobody can enumerate is one two vendors implement very differently while both claim conformity. The call for Commission guidance or a harmonised standard on the category boundary stays.

@eeee2345 — took the pinning suggestion: the SPEC is cited at fd0f67f, the last commit touching that file, so it cannot move. Cited strictly as feasibility evidence, with the third-party status and the FAQ's neutrality on it stated inline.

(2)(f). Reworded to your reading, which is better than what we drafted. The old text asserted Annex I does not require log integrity and parked (2)(f) in a parenthesis as being about something else. (2)(f) runs to "stored, transmitted or otherwise processed data", a security log is processed data, and Annex I neither singles it out nor excludes it — so the answer now states a genuine ambiguity rather than a gap, and adds the consequence: a self-attested log an agent can write to itself is within reach of whoever has taken over that agent's actions.

No mechanism is seated. Anchoring, issuer signatures and external witnesses are all left out on purpose — agreed with you that "this is unsettled and here is why it matters" serves a reader better, and neither of our preferences belongs in a FAQ answer. My interest here is on the record in the thread above.

Ready for the task force; happy to take further comments on the merits in the meantime.

[eeee2345]

@tyche-dev thanks for the careful incorporation — the event-class decomposition reads well as illustrative-not-exhaustive, and keeping it descriptive of what an agent does rather than prescriptive of what a manufacturer must record reads to me as the right line for a FAQ. As the SPEC author I can confirm the pinned reference at fd0f67f faithfully reflects the SPEC: AgentEvent is defined there as a structured representation of an AI agent action (LLM I/O, tool call, context window state), the event-class set is left open for extension, and the trust-boundary section is present as cited. I'd also underline your framing that this is third-party feasibility evidence and not an endorsement — whether the Annex I (2)(l) log category should be enumerated, and how, is properly a matter for Commission guidance or a harmonised standard, not for a FAQ, or for me, to settle. If it's useful to the task force, I'm happy to answer questions about the event taxonomy.

[tyche-dev]

@eeee2345 thank you — author-level confirmation of a pinned citation is worth more than our own reading of it, and it settles the question for the FAQ.

One note for the record rather than for you to action: now that you have commented here, "third-party work" in the answer stays accurate in the sense meant — third-party to the FAQ, not to this thread — but if the task force would rather the text said so explicitly, that is an easy edit.

Agreed on scope, and I would extend it in your direction: whether the Annex I (2)(l) category should be enumerated is not ours to settle either. The answer stops at enumerability being practicable and leaves the boundary to guidance or a harmonised standard.

Separately, and while you have the file open: I have just pushed a correction to the paragraph below the one you reviewed. Our quotation of Annex I (2)(f) stopped at "not authorised by the user" and closed there, dropping ", and report on corruptions" with no ellipsis. That clause is the nearest the Annex comes to an obligation about the condition of recorded data, which is exactly what the paragraph is arguing about, so quoting around it read as selective rather than tidy. It is now restored, with two sentences that account for it: the duty to report corruptions exists, and the Annex does not say how a corruption is to be detected. No mechanism is proposed and the answer's position is unchanged. The branch also now carries a sign-off on every commit.

On the taxonomy offer — it was made to the task force, so I will leave it there rather than take it up privately. The next scheduled FAQ Task Force call is Tuesday 1 September, 15:30 CEST. Nothing needed from you meanwhile; the offer stands on the record.