EU AI Act Conformity Record

1. General description of the AI system

• System name: SalesSynq AI Assistant (the "Assistant").
• Provider: SalesSynq (legal entity as identified in the Order Form).
• Intended purpose: to summarise pipeline, deals and signals on request from authenticated business users; to recommend next-best actions; to call read-only back-end tools when explicitly directed by the user. The Assistant is deployed inside a B2B revenue-operations SaaS product.
• Intended users: employees and contractors of SalesSynq Customers acting in a sales, customer-success, marketing or operations capacity.
• Hardware and software environment: Cloud-hosted multi-tenant SaaS. The Assistant is composed of a deterministic Java service (Synq Score, audit chain, tenant isolation), a Python orchestration service, and an LLM provider for suggested text generation. Browsers run only client-side rendering; no model executes on user devices.
• Foreseeable and reasonably-foreseeable misuse: attempts to use the Assistant to make automated decisions producing legal or similarly significant effects on individuals (e.g. hiring, dismissal, credit) without independent human review. The Acceptable-Use clause of the Terms of Service prohibits this.
• Out of scope: the Assistant is not designed for, marketed to, or deployed in any of the use cases listed in Annex III of the AI Act (employment, education, essential services, law enforcement, migration, justice, biometrics, critical infrastructure).

2. Risk classification under the EU AI Act

Conclusion: the Assistant is a limited-risk AI system subject only to Article 50 transparency obligations. Conformity assessment under Article 43 is not required. This record is maintained voluntarily.

3. Detailed description of system elements (Annex IV §2)

3.1 System architecture

• Deterministic core. Owns Customer-facing scoring (Synq Score, risk likelihood, progress trend, similar-deal comparison, workflow integrity), tenant isolation, audit logging with chain sealing, and the privacy / DSAR workflow. Outputs from this layer are reproducible: the same input produces the same score.
• AI orchestration. Constructs prompts for suggested-action tasks (summaries, signal extraction, suggested next steps), redacts common PII categories before the prompt leaves the box, calls the LLM provider, validates and parses the JSON response, and fails closed without materialising an AI selection on parse failure or upstream error.
• Context resolution. Detects unresolved CRM or Slack context gaps and labels them as AI-assisted decision support. Auto-multi attribution is allowed only when the deterministic resolver sees the same non-null company and same non-null product fingerprint across all candidates; otherwise the gap stays pending for human review.
• Recommended next moves. Deal-page recommendations are AI-assisted decision support backed by deterministic bundle rules. A user must explicitly start the recommendation before SalesSynq creates a follow-up task; CRM-write steps require a separate acknowledgment because SalesSynq reads from HubSpot but does not write back to it.
• MCP go-to-market ingestion gateway. OAuth-registered external agents may submit canonical go-to-market envelopes into a deterministic ingest ledger. The gateway validates tenant binding, schema version, idempotency key, content hash, source history, data classification and scopes before queueing materialisation through the multi-node integration work queue.
• LLM provider. Currently OpenAI (gpt-4o-mini for semantic enrichment); provider-side "do not use my data for training" is applied at the org level on the production OpenAI account, and we have applied for OpenAI Zero-Data-Retention. Region-aware: tenants pinned to LLM_REGION=eu route to Azure OpenAI in an EU region (operated by Microsoft Ireland Operations Limited).

3.2 Data and data governance

• Training data. SalesSynq does not train, fine-tune or distil any model. Foundation-model selection and training data are the responsibility of the upstream LLM provider. The Assistant's behaviour is shaped through prompt construction, retrieval and validation — not training.
• Customer Data is never used to train any model. This is a contractual commitment in the DPA. Operationally, we apply each LLM provider's "do not use my data for training" toggle at the production-org level (the operative control on the OpenAI account); we have applied for OpenAI Zero-Data-Retention; equivalent steps will be taken for any new LLM Sub-processor before it joins the active list.
• Input data at inference. Free-text content from the Customer's connected systems and the user's prompt. PII categories (emails, phone numbers, IBANs, payment cards, IP addresses) are redacted before transmission to the LLM provider.
• Agent-originated go-to-market data. MCP ingestion accepts Customer Data supplied by customer-approved agents. The direct ingest path is deterministic and does not send submitted payloads to an LLM; source history, generated-content flags and the agent-supplied confidence are retained for downstream transparency.
• Data quality measures. Inputs are validated against per-feature schemas before scoring. Cross-tenant queries are blocked at the repository layer by an isolation aspect that rejects any access whose tenant context disagrees with the entity's tenant_id.
• Bias and representativeness. Customer-facing scoring is rule-based on Customer's own data; the rules apply uniformly across customers and segments. LLM suggested text may inherit foundation-model biases; we mitigate by (i) using a JSON-only response format with a typed schema, (ii) failing closed on parse failure, and (iii) never auto-executing decisions that affect individuals without explicit user approval.

3.3 Monitoring, functioning and control

• Per-call source trail. Each LLM invocation records the model version, prompt template version, latency, parse status, and pseudonymous tenant identifier. PII redaction counts (not values) are recorded for auditability.
• Context-resolution source trail. Each AI-assisted context decision records resolver version, rule version, candidate facts used, primary deal id, sorted attributed deal ids, actor, timestamp, action source, input hash, output hash, and evidence record id.
• Recommendation-start source trail. Each started recommendation records the rule id, policy version, model version, bundle version, context snapshot hash, ACTION_ACCEPTED ledger event, execution outbox id, task id, and optional Jira or Linear route reference.
• MCP ingest source trail. Each accepted agent-originated go-to-market envelope records OAuth client id, agent user id, object type, external id, idempotency key, payload hash, content hash, source history, generated-content flag where supplied, materialisation status, hold reason and replay count.
• Append-only audit log. Tool calls, approvals and configuration changes are written to a chain-sealed audit log retained for 365 days by default.
• Human oversight. Tools that read or modify Customer Data require explicit user approval before execution. The Assistant cannot autonomously initiate actions on the user's behalf without either (i) a one-time approval or (ii) standing user configuration. MCP OAuth client approval, revocation, schema-policy changes, hold release and replay remain administrator-controlled.
• Determinism boundary. Customer-facing scoring is rule-based and reproducible. LLM output is suggested text and is never load-bearing for a numeric score that drives commercial decisions.

4. Risk management system (Art. 9 / Annex IV §3)

A continuous risk-management process is operated for the lifecycle of the Assistant. The four steps below are repeated on every material change.

1. Identify. Hazards considered include: prompt injection, data leakage to provider, hallucination, cross-tenant leakage, denial-of-service through cost amplification, misuse for prohibited downstream decisions, regulatory exposure of the LLM provider.
2. Estimate and evaluate. Each hazard is rated for likelihood and severity in a private risk register. The register is reviewed at every release.
3. Adopt risk-management measures. Mitigations in place: PII redaction upstream of LLM; provider-side "do not train"; per-tenant pseudonymous identifier on each LLM call; cost manager with hard token budget per request (30 000 token soft budget; $0.005 hard cap); rate limiting on auth and tool-call endpoints; fail-closed handling on parse failure; Acceptable-Use clause prohibiting Annex III use.
4. Test residual risk. Static analysis (CodeQL) on every PR; OWASP Dependency-Check on every PR with CVSS ≥ 7 fail-the-build; Gitleaks pre-commit. Annual third-party penetration test planned (vendor selection in progress; engagement target before first paying Customer). Tenant-isolation regression tests run on every commit.

5. Changes through the lifecycle (Annex IV §4)

Changes to model version, prompt template, scoring rules, or risk-management measures are recorded in the engineering change log and reflected in the policy version exposed at /api/compliance/ai-disclosure. The current version is shown on the AI Disclosure page. Material changes affecting Customers are notified in the product release notes.

6. Harmonised standards and frameworks applied (Annex IV §5)

The Assistant is engineered against the following standards and frameworks. None of the harmonised standards under Article 40 of the AI Act are yet final at the date of this record; SalesSynq commits to adopting them as they are published and to updating this record accordingly.

• EU GDPR (Regulation (EU) 2016/679) — data protection by design and by default.
• ISO/IEC 27001:2022 — information security management (readiness in progress; no certification claimed).
• ISO/IEC 42001:2023 — AI management systems (used as a structuring reference for this record).
• NIST AI Risk Management Framework (AI RMF 1.0) — structuring reference for the risk-management process in Section 4.
• OWASP Top 10 for LLM Applications (2024) — threat model reference for the AI orchestration layer.
• OWASP Application Security Verification Standard (ASVS) v4 — secure-development reference for the wider product.

7. Article 50 transparency — how it is discharged

• Public AI Disclosure page at /ai-disclosure describes what the Assistant does, what is logged, and how to opt out.
• In-product labelling. AI-generated content is rendered with explicit visual cues so users can distinguish it from data drawn directly from the CRM.
• Context attribution labelling. CONTEXT_GAP rows and auto-multi attributions are labelled as AI-assisted decision support. Pending Cases is the human action point for Attribute and Dismiss, and the audit trail is available in the compliance dossier.
• Recommended-next-move labelling. Start controls state that the recommendation is AI-assisted and human-started. External CRM-write steps name the external system and required field before the task is queued.
• Agent-originated data labelling. Data submitted through MCP carries the originating agent's source history, supplied confidence and generated-content markers so downstream users can distinguish customer-entered records from agent-originated evidence.
• Approval prompts. Tool calls that read or modify Customer Data require explicit user approval; the user sees the proposed action before it executes.
• Right to human review. A user who wishes to dispute an Assistant output can request human review by writing to support@salesynq.com or to the workspace administrator.

8. Post-market monitoring (Art. 72 / Annex IV §9)

A post-market monitoring procedure is operated continuously for the Assistant.

• Telemetry. Per-call latency, parse-failure rate, no-materialisation rate, and PII-redaction counts are recorded and reviewed weekly.
• MCP ingest monitoring. Accepted, duplicate, rejected, held, failed, materialised and replayed envelope counts are monitored by tenant and OAuth client. Queue depth, lease recovery and work-item retry metrics are included in operational review.
• User feedback channel. Users may flag any Assistant output via the in-product feedback affordance or by writing to support@salesynq.com.
• Incident handling. Serious incidents within the meaning of Art. 73 of the AI Act would be reported to the relevant Member-State authority within the regulatory deadline, in addition to the GDPR Art. 33 breach-notification process where personal data is involved.
• Compliance dossier. A live, per-subsystem compliance dossier is exposed to administrators at /api/v3/compliance/dossier, including model cards, classification rationale and audit-chain hashes.

9. Voluntary classification statement

10. Cross-references

• /ai-disclosure — live, per-subsystem AI classification.
• /legal/dpa — Data Processing Agreement; Annex II Technical and Organisational Measures.
• /legal/terms — Acceptable Use and Article 22 GDPR limitation.
• /security — security questionnaire and concrete controls.
• /trust/subprocessors — the LLM Sub-processors used by the Assistant.
• /privacy — the Privacy Policy.