EU AI Act Preliminary Classification 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: deal-, account- and aggregate team-level B2B revenue-operations decision support: summarising pipeline, deals and signals; recommending human-reviewed next actions; and calling authorised back-end tools when directed by a user.
• 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 combines deterministic services, layered tenant controls, a Python orchestration service, and configured LLM providers for suggested text generation. Browsers render the client interface; deployment-specific provider and service configuration must be confirmed separately.
• Prohibited worker uses: rep ranking; individual-performance monitoring; and use for compensation, promotion, appraisal, discipline, PIP, dismissal or termination. These restrictions apply even where a customer proposes human review.
• Other prohibited purposes: any Annex III employment or worker-management use and any solely automated adverse decision. Connectors must declare their intended purpose and are rejected when that purpose matches a prohibited category.

2. Risk classification under the EU AI Act

Preliminary conclusion: the live control-catalogue status shown above governs this record. The limited-risk posture applies only to the declared intended purpose. No final legal classification or Article 43 conclusion is claimed before counsel sign-off.

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

3.1 System architecture

• Deterministic services. Numeric scoring and selected workflow controls use versioned deterministic logic when their required evidence is available. Tenant protection is defense-in-depth: scoped queries and authorisation checks are supplemented by repository argument/result validation where tenant context and tenant-aware entities are present.
• AI orchestration. Supported orchestration paths construct prompts for summaries, signal extraction or suggested next steps, apply deterministic common-pattern redaction before provider egress, and validate structured responses. Coverage and guardrail policy vary by path; regex redaction can miss personal data and is not a guarantee of anonymisation.
• 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. Provider, model, region and retention configuration can vary by deployment. For an enabled provider, SalesSynq configures available controls intended to prevent provider training on Customer Data. An OpenAI Zero-Data-Retention request has been submitted, but approval is not claimed. EU routing is available only when the applicable Azure OpenAI configuration is actually enabled.

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.
• No SalesSynq training on Customer Data. SalesSynq contractually commits not to use Customer Data to train or fine-tune models. Provider-side handling remains governed by the enabled provider's contract and configured controls; Zero-Data-Retention approval is not assumed.
• Input data at inference. Free-text content can include data from connected systems and a user prompt. Supported paths redact common email, phone, IBAN, payment-card and IPv4 patterns before provider egress. The pattern set is limited, path coverage is not universal, and customers should not treat it as complete de-identification.
• 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 and tenant controls. Per-feature validation is used where implemented. Tenant protection combines scoped queries, OpenFGA checks where configured, and repository argument/result validation for tenant-aware values when authenticated tenant context exists. Strict null-tenant handling is configurable, so the repository aspect is an additional fence rather than universal query scoping.
• Bias and representativeness. Supported scoring paths use versioned rules over the available Customer evidence and tenant configuration. That design does not establish statistical parity, absence of bias, or uniform outcomes across customers and segments. LLM-derived or suggested content may inherit foundation-model biases; path-specific mitigations include typed structured responses, parse-failure handling and human oversight for consequential actions.

3.3 Monitoring, functioning and control

• Instrumented-call source trail. Supported AI paths record available model, prompt-version, latency, parse-status and pseudonymous-tenant metadata, plus redaction counts where the redactor is in that path. Telemetry coverage must be assessed per integration; this is not a claim about every LLM invocation.
• 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. Tool policy distinguishes reads, mutations and external effects. Some reads operate under existing user permissions; mutations and external actions use the applicable approval or standing-configuration policy. Administrator-controlled connector and replay operations remain separately authorised.
• Determinism boundary. Where an eligible numeric score is emitted, a versioned rule evaluator produces the numeric result from the accepted inputs and configuration. AI-assisted extraction can contribute upstream evidence on supported paths, so reproducibility depends on the recorded inputs, versions and publication receipt. The score remains decision support, not an automated commercial decision.

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. Implemented or path-specific mitigations include common-pattern redaction on supported orchestration paths, configured provider-training controls, pseudonymous tenant metadata on the primary instrumented path, request budgets, rate limits on selected endpoints, structured-response validation and intended-purpose restrictions. None of these controls alone guarantees complete PII removal or tenant isolation.
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 following standards and frameworks are design references, not certifications or completed legal assessments. Applicability and implementation coverage remain subject to evidence review and counsel advice.

• EU GDPR (Regulation (EU) 2016/679) — privacy-control design reference; readiness and legal review remain in progress.
• 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 controls and open items

• Public AI Disclosure page at /ai-disclosure describes what the Assistant does, what is logged, and how to opt out.
• In-product labelling. Supported AI surfaces are designed to render generated or AI-assisted guidance with visual cues and a human-review reminder. Coverage must be verified per surface; this record does not claim that every generated field is labelled in every deployment.
• Machine-readable text-output marking. Ordinary Assistant responses carry a versioned first-party JSON source history envelope through non-streaming responses, streaming final events, persisted chat metadata and transcript reads. The envelope distinguishes AI-generated, deterministic and other non-AI output; binds the marker to an output SHA-256; and records available provider, model and trace identifiers. This is an application-layer control. Cross-platform robustness, interoperability and the final legal scope of Art. 50(2) remain under assessment.
• 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 policy. Tool policy distinguishes reads, mutations and external effects. Some reads operate under existing user permissions; mutations and external actions use the applicable approval or standing-configuration policy. This is not a claim that every read displays a separate prompt.
• Right to human review. A user who wishes to dispute an Assistant output can request human review by writing to [email protected] or to the workspace administrator.

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

SalesSynq is building a post-market monitoring procedure. The controls below describe intended and currently instrumented coverage; this page is not proof of continuous monitoring.

• Telemetry. Instrumented paths can record latency, parse failures, no-materialisation outcomes and redaction counts. Collection and review coverage varies by path and environment.
• 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 [email protected].
• 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. Authorised administrators can access dossier data where the corresponding backend deployment and evidence producers are available. An endpoint existing in code does not by itself certify completeness.

9. Preliminary classification statement

10. Cross-references

• /ai-disclosure — catalogue-backed preliminary disclosure, not a final legal 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.