> For the complete documentation index, see [llms.txt](https://wiki.fridays.bot/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.fridays.bot/documentation/white-paper/12.-compliance-and-ai-governance.md).

# 12. Compliance and AI Governance

This section maps Fridays to the AI-specific regime layered atop the data-protection obligations of §9. The through-line: **the §6 approval model is not only the product's differentiator and its injection backstop — it is the single control that most regulatory frameworks converge on requiring** (meaningful human involvement / oversight / review). Fridays' architecture front-runs these obligations because the same mechanism satisfies GDPR Art. 22, the EU AI Act's oversight expectations, and Colorado's human-review right. This is design leverage, not coincidence: build the control once, satisfy the convergent regimes.

*This section is engineering-facing regulatory analysis, not legal advice; positions are stated with their statutory hooks so counsel can verify. Effective dates and instruments below are current as of July 2026 and are moving — the Digital Omnibus and Colorado rulemaking are both live.*

#### 12.1 EU AI Act (Regulation (EU) 2024/1689): Article 50 transparency

Article 50 transparency obligations apply from **2 August 2026**, backed by fines up to €15M or 3% of worldwide turnover (Art. 99(4)) \[1]\[3]. Fridays' exposure is narrower than a generative-media product's, and precisely delimiting it matters because over-compliance here is wasted engineering:

* **Art. 50(1) — AI-interaction disclosure (applies).** Systems that interact directly with natural persons must inform them they are dealing with AI, unless obvious \[1]. Fridays interacts with the *tenant* (the owner knows they use an AI product) but also emits communications to the tenant's *customers* (invoice reminders, replies). Whether the recipient is "interacting directly with an AI system" under 50(1) is the live question. Position: Fridays treats owner-approved outbound communications as **the tenant's communications, sent under the tenant's authority** — the human-approval step (§6) makes the owner the sender, not the AI, which is the same act as a bookkeeper using mail-merge. Where a Fridays surface *does* converse directly and non-obviously with an end user, 50(1) disclosure is provided at first interaction per Art. 50(5)'s clear-and-accessible standard. This is a defensible reading, not a settled one; the Commission's draft Guidelines (8 May 2026) address 50(1) scope and are tracked \[4].
* **Art. 50(2) — machine-readable marking of synthetic content (largely inapplicable, by carve-out).** Providers of generative AI producing synthetic audio/image/video/**text** must mark outputs as machine-readable AI-generated \[1]. Two reasons Fridays sits mostly outside this:
  1. **Express carve-out.** 50(2) does not apply where the system "performs an assistive function for standard editing or does not substantially alter the input data provided by the deployer or the semantics thereof" \[1]\[3]. An invoice reminder assembled from the tenant's own invoice data and prior thread context is closer to templated assembly than to novel synthetic generation — the assistive-editing/no-substantial-alteration carve-out is the operative argument.
  2. **Scope by content type.** The marking regime targets deception risk in the information ecosystem — deepfakes and synthetic media \[2]. A business email to a known counterparty is not the mischief 50(2) addresses.
  * Timeline hedge: *if* any Fridays output is later deemed in scope, the Digital Omnibus provisional agreement (7 May 2026) grants systems already on market before 2 Aug 2026 a transition to **2 December 2026** for the marking requirement specifically; systems entering after 2 Aug 2026 get no grace \[3]\[4]. The Omnibus is not yet adopted law — treated as planning input, not relied upon \[4].
* **Art. 50(4) — deepfake labelling (not applicable).** Fridays generates no image/audio/video deepfakes.
* **High-risk (Title III) — not applicable, but adjacent.** Fridays does not perform Annex III high-risk functions (it is back-office automation, not credit scoring or employment decisioning). Note the Omnibus defers Annex III obligations to **2 December 2027** \[3] — relevant only as a boundary Fridays must not drift across (e.g., a future playbook that scored loan applications would cross it).

**Engineering consequence:** the marking machinery (C2PA/watermarking \[2]) is *not* built into outbound business communications now, because the carve-out and scope analysis say it's not required and marking a debtor's reminder email as "AI-generated" would be actively counterproductive to the tenant's relationship. The decision is documented with its statutory basis so it survives review; the C2PA path is kept as a contingency wired to the Guidelines' finalization.

#### 12.2 FTC Act §5: substantiation of automation claims

Fridays' US baseline. The FTC's "Operation AI Comply" (2024) and repeated guidance establish that AI-related marketing claims must be **substantiated**, and that §5's deception/unfairness authority reaches AI products directly \[5]. Two exposures:

* **Claim substantiation.** "Fridays chases your invoices," "handles your books" — performance claims requiring evidence. The eval harness (§11) *is* the substantiation infrastructure: per-risk-class precision/recall (§11.2) measured against golden datasets is exactly the "competent and reliable evidence" §5 substantiation demands. A product making capability claims about probabilistic components without §11's measurement is exposed on substantiation regardless of whether the claims are true.
* **Avoiding "AI washing" and overstatement.** Claims must not overstate autonomy. Fridays' honest framing — approval-gated, "you approve what matters" — is not only product-accurate; it is the conservative posture §5 rewards. The §7 audit log substantiates *what actually happened* per tenant if a claim is ever challenged.

#### 12.3 GDPR Article 22 and the approval model

Fully argued in §6.4; summarized here as the compliance-mapping anchor. Art. 22(1) restricts decisions "based solely on automated processing" with legal/significant effects; WP251rev.01 requires human involvement that is **meaningful** — authority and competence to change the decision, applied before effect \[6]\[7]. Fridays' approval gate (§6.3–6.4) implements exactly this: the owner has maximal authority, the card supplies decision-relevant data for competence, and suspension is causally pre-effect. The novel point for *this* section: Art. 22 compliance and the §8.2 injection defense are **the same mechanism viewed from two regimes** — the human tap that a prompt-injection attacker cannot supply (§2.4 TB2) is the same human decision that removes the action from "solely automated" processing. One control, two regulatory dividends.

#### 12.4 Colorado AI Act (SB 26-189, the ADMT Act)

The most-cited US state AI law was **repealed and replaced** in flight — a caution against building to any single unstable statute. Colorado's original SB 24-205 (risk-based, duty-of-care, bias audits, EU-modeled) was repealed by **SB 26-189, the Automated Decision-Making Technology Act**, signed 14 May 2026, effective **1 January 2027** \[8]\[9]. The rewrite discards the duty of care, risk-management-program, and impact-assessment mandates in favor of a disclosure-and-rights framework \[8]\[9]\[10]. Current status noted for planning: AG rulemaking must complete by 1 Jan 2027, and enforcement sits under a federal litigation stay (xAI) that expressly reaches the replacement law \[9] — the contours below may shift in rulemaking.

Applicability analysis:

* **Scope — likely narrow or out.** SB 26-189 covers a "covered ADMT" that "materially influences" a "consequential decision" (lending, housing, employment, health care, insurance, education) \[8]\[10]. Fridays' back-office playbooks — chasing invoices, triaging email, tidying a CRM — are not consequential decisions in this sense. The replacement law's **extensive carve-outs** (routine technologies, low-stakes decisions, fraud prevention, cybersecurity, advertising) further narrow scope \[10]. A reminder to a business debtor is not a consequential decision about a consumer.
* **Where it *****would***** bite, Fridays already conforms.** SB 26-189's operative consumer rights on an adverse outcome are (a) a plain-language explanation within 30 days and (b) **meaningful human review with override authority — "designated trained individuals … who do not default to system output"** \[8]\[10]. This is a near-verbatim description of the §6 approval model: the owner/delegate is the designated human with override authority, and the §6.2 ratchet plus false-approval-request objective (§11.2) exist precisely to prevent defaulting to system output (rubber-stamping). The §7 audit log supplies the explanation substrate. If a future Fridays playbook ever entered a consequential-decision domain, the human-review requirement is already satisfied by construction; the missing piece would be the post-adverse-outcome *notice workflow*, which is a disclosure feature, not an architectural change.
* **Contract hygiene flagged.** SB 26-189 may void certain developer↔deployer indemnification clauses as against public policy \[10]; Fridays' tenant agreements are reviewed against this before the effective date.

#### 12.5 AI disclosure surface

The concrete artifacts implementing the above, and where each obligation lands:

* **Public AI disclaimer page** — mapped to the operative requirements (EU AI Act Art. 50 transparency, FTC §5 honesty, GDPR Art. 22 automated-decision disclosure, CCPA/CPRA). Maintained against the moving instruments in this section, versioned.
* **In-product labeling** — Fridays identifies as AI within the owner's experience by default (the owner is never deceived about interacting with an AI); Art. 50(1) is trivially met on the tenant side.
* **Outbound-communication stance** — owner-approved communications carry the tenant's identity as sender (§12.1); no "generated by AI" marking is applied to business correspondence, a decision documented with its 50(2)-carve-out basis (§12.1).
* **Model/data transparency for tenants** — the honest, precise answer to "does it learn from my data" (§9.5: threshold state only) and "what does it send to third parties" (§9.3: pseudonymized, no-training) is published, because vague answers here are both a trust failure and, increasingly, a disclosure-compliance failure.
* **llms.txt** — machine-readable product description for AI crawlers. Included as good practice with the caveat that adoption is limited and no major AI provider has committed to consuming it — worth doing, not worth relying on.

**Governance posture, stated once:** every position in this section is documented with its statutory hook and its supporting mechanism (eval metrics, audit log, approval design), so compliance is *demonstrable from the systems described in §§5–11* rather than asserted — the same "evidence is a byproduct of the architecture" principle as the SOC 2 mapping (§8.6). Where the law is unsettled (Art. 50(1) recipient scope, the Omnibus, Colorado rulemaking), the conservative reading is taken and the contingency is wired, not deferred.

***

#### References (Section 12)

\[1] Regulation (EU) 2024/1689 (AI Act), Article 50 — transparency obligations; Art. 50(1) interaction disclosure, 50(2) machine-readable marking and its assistive-editing/no-substantial-alteration carve-out, 50(4) deepfake labelling, 50(5) clarity/accessibility; Art. 99(4) fine tier (€15M / 3%). <https://artificialintelligenceact.eu/article/50/>

\[2] Commission Code of Practice on Transparency of AI-Generated Content (published 10 June 2026) — marking/detection mechanisms (C2PA Content Credentials named by example); voluntary but the de facto compliance benchmark for 50(2)/50(4). <https://digital-strategy.ec.europa.eu/en/policies/code-practice-ai-generated-content>

\[3] Digital Omnibus on AI, provisional agreement (7 May 2026) — transition to 2 Dec 2026 for 50(2) marking on systems already on market before 2 Aug 2026; Annex III high-risk deferral to 2 Dec 2027. Not yet adopted law as of this writing; treated as planning input. (Commission/Parliament materials; secondary analysis: ComplianceHub, Covington Global Policy Watch, May 2026.)

\[4] European Commission, Draft Guidelines on Article 50 (8 May 2026; consultation closed 3 June 2026) — first Commission instrument interpreting Art. 50 scope, incl. 50(1) and "technically feasible" as an objective standard not scaled to provider size. <https://www.globalpolicywatch.com/2026/05/10-takeaways-european-commission-draft-guidelines-on-ai-transparency-under-the-eu-ai-act/>

\[5] US FTC, Section 5 (deception/unfairness) as applied to AI; *Operation AI Comply* (Sept 2024) and Bureau of Consumer Protection guidance on substantiation of AI performance claims and "AI washing." <https://www.ftc.gov>

\[6] Regulation (EU) 2016/679 (GDPR), Art. 22. <https://eur-lex.europa.eu/eli/reg/2016/679/oj>

\[7] Article 29 Working Party, WP251rev.01 (2018, EDPB-endorsed) — "meaningful" human involvement standard (per §6.4).

\[8] Colorado SB 26-189, *Automated Decision-Making Technology Act* — signed 14 May 2026, effective 1 January 2027; repeals and replaces SB 24-205; disclosure + adverse-outcome explanation (30 days) + meaningful-human-review rights; "materially influences" a "consequential decision." Colorado General Assembly. <https://leg.colorado.gov>

\[9] Enforcement/litigation status: AG rulemaking due by 1 Jan 2027; federal stay in the xAI action reaching the replacement law (Apr–June 2026). Norton Rose Fulbright; Seyfarth (May 2026 analyses).

\[10] Scope, carve-outs (routine tech, low-stakes, fraud/cybersecurity, advertising), human-review-with-override requirement, and indemnification-clause voidability under SB 26-189. Baker Botts; Troutman Pepper Locke (May 2026 analyses).

***

*Next: Section 13 (Performance and Cost Model).*

***

### As-Built Reconciliation — V1

*Legend/sources as in §1's addendum. Whole section → companion `ai-governance-v1.md`.*

**This section's legal analysis is already current and correct** — it cites the corrected instruments (SB 26-189, the Digital Omnibus, Art. 50 dates, the assistive-editing carve-out). Reconciliation therefore mostly confirms it and maps each obligation to the EXISTING approval primitives vs. PLANNED product surface.

| §                                                                       | Status                               | As-built (source)                                                                                                                                                                                                                             |
| ----------------------------------------------------------------------- | ------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| 12.1 EU AI Act Art. 50                                                  | **analysis sound; controls PLANNED** | Approval step (owner = sender) is the 50(1) position; 50(2) carve-out holds. Marking machinery correctly **not** built. Surface-classification record + disclaimer page — PLANNED.                                                            |
| 12.2 FTC substantiation                                                 | **dependency unbuilt**               | Rests on the §11 eval harness, which **does not exist**. The claim-reconciliation discipline *does* exist as FTC-hygiene (MR §4).                                                                                                             |
| 12.3 GDPR Art. 22                                                       | **EXISTS (substrate)**               | Review stages, self-review excluded, decision comments (SC §5). Companion §3.                                                                                                                                                                 |
| 12.4 Colorado SB 26-189                                                 | **correct; likely out of scope**     | Human-review-with-override already satisfied by the approval model; only the post-adverse-outcome notice workflow would be additive. Companion §5.                                                                                            |
| 12.5 Disclosure surface (disclaimer, in-product labeling, **llms.txt**) | **PARTIAL**                          | `llms.txt`/`llms-full.txt` **EXIST** on the site (TS §2.1); disclaimer page + in-product AI labeling — PLANNED; reconcile via claim-correction (MR §4). Site currently **overstates** SOC 2 / MFA / isolation (SC §11) — Phase-1 corrections. |

**Flag:** the regulatory *reasoning* is the most launch-ready part of the paper. Its **evidentiary backing** is what lags: FTC substantiation (§12.2) needs the unbuilt eval harness (§11), and Art. 22 evidence (§12.3) is strongest with a DB-immutable audit log (§7.1, currently app-convention only). The compliance posture is sound; the systems that *prove* compliance are partly aspirational.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://wiki.fridays.bot/documentation/white-paper/12.-compliance-and-ai-governance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.