EU AI Act overview
How the InstaLILY platform's controls correspond to the Regulation, and where responsibility sits between us and our customers.
Purpose and status
This document explains how InstaLILY approaches Regulation (EU) 2024/1689, the Artificial Intelligence Act, as amended. It is written for security, privacy, and procurement teams evaluating the platform, and it is intended to be read alongside our SOC 2 Type II report and our GDPR and data processing pack.
It is a statement of correspondence, not a declaration of conformity. InstaLILY has not undergone a conformity assessment, holds no CE marking for an AI system, and has not been assessed by a notified body. What follows describes engineering and governance controls we already operate, and how those controls line up with what the Act asks of high-risk systems. Where an obligation has not yet been triggered for us or for a customer, we say so.
InstaLILY's European deployments are beginning now. This document reflects our position as of August 2026 and will be revised as deployments and the Regulation develop.
Where the Act currently stands
The compliance calendar changed materially in mid-2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, was published in the Official Journal on 24 July 2026 and entered into force on 27 July 2026. It deferred the high-risk obligations but left the transparency obligations on their original date. Buyers working from the pre-Omnibus timeline should note the following.
| Date | What applies | Status |
|---|---|---|
| 2 Feb 2025 | Article 5 prohibited practices; AI literacy obligations | In force |
| 2 Aug 2025 | General-purpose AI model obligations, Articles 51 to 56 | In force, unaffected by the Omnibus |
| 2 Aug 2026 | Article 50 transparency obligations; enforcement begins at national and EU level | In force, not deferred |
| 2 Dec 2026 | Article 50(2) marking for systems already on the market before 2 Aug 2026; new prohibited categories added by the Omnibus | Pending |
| 2 Dec 2027 | High-risk obligations for standalone Annex III systems | Deferred from 2 Aug 2026 |
| 2 Aug 2028 | High-risk obligations for AI embedded in regulated Annex I products | Deferred from 2 Aug 2027 |
The practical consequence is that the transparency regime and enforcement are live today, while the high-risk regime is not yet in application. We have not treated the deferral as a reason to defer the underlying controls, all of which were built for reasons that predate the Act.
Roles under the Act
The Act allocates obligations by role, and the same software can carry different obligations depending on who is doing what with it.
| Role | Who | What it means here |
|---|---|---|
| Provider | InstaLILY, Inc. | We develop the platform and place it on the market under our own name. Provider obligations attach to us. |
| Deployer | The customer | You use the platform under your own authority, configure which agents run, which systems they reach, and which actions require human approval. Deployer obligations attach to you. |
| GPAI providers | Google, OpenAI, Anthropic | The general-purpose models we call for inference are supplied by third parties who carry the Chapter V obligations for those models. We are a downstream provider integrating them. |
One boundary worth stating plainly: a deployer who substantially modifies the system, or puts it on the market under their own name and brand, can become a provider in their own right and take on the corresponding obligations. If you intend to do either, raise it with us during implementation.
How InstaLILY deployments classify
Prohibited practices: Article 5
None. The platform automates sales and operational workflows across ERP, CRM, and data-warehouse systems. It is not built for, and is not offered for, social scoring, untargeted facial-image scraping, emotion inference in the workplace or in education, biometric categorisation of protected characteristics, or the practices added to Article 5 by the Omnibus.
High-risk: Annex III
A standard InstaLILY deployment does not fall within Annex III. Quoting, pricing support, parts identification, supplier and inventory workflows, service triage, and territory or account operations are not among the listed categories.
Classification is determined by use, not by the software, and a customer can configure agents in a way that changes the answer. The areas to watch:
- Employment and worker management, if agents are configured to screen candidates, allocate tasks, or inform decisions about promotion, termination, or performance monitoring.
- Access to essential private or public services, including creditworthiness evaluation and risk pricing in life or health insurance.
- Any other Annex III category that a specific configuration touches.
If a deployment is heading toward any of these, tell us during implementation. We will document the configuration, and the conformity, registration, and fundamental-rights-impact obligations get planned deliberately rather than discovered later.
Transparency: Article 50
These obligations are live now. Where agents interact directly with a natural person, that person must be informed they are interacting with an AI system unless it is obvious from the context. Where an agent generates synthetic content, marking and disclosure requirements can apply. Because the deployer controls where agents are surfaced and to whom, meeting these obligations is a shared exercise: we provide the attribution and logging described in section 5, and you determine the disclosure your use requires.
Control correspondence
The six gates every agent action passes through were built as engineering controls, before and independently of the Act. The table below maps them, and the surrounding platform controls, to what the Regulation asks of high-risk systems. The evidence column names the document a reviewer can ask for.
| Article | Requirement | Corresponding InstaLILY control | Evidence |
|---|---|---|---|
| Article 9 | Risk management system | Annual risk assessment with a maintained risk register; AI and ML systems are subject to the same risk and security review as other production systems, explicitly including misuse, bias, and unintended impact. | SOC 2 CC3.1 to CC3.4; AI/ML Policy |
| Article 10 | Data and data governance | Each customer runs in a dedicated single-tenant Google Cloud project. No cross-customer models may be trained. Training, fine-tuning, and inference data stays inside the customer boundary, and inference outputs are treated as customer-derived information subject to the same isolation. External data is pre-sanitised at ingestion. | SOC 2 system description; AI/ML Policy; Data Classification Policy |
| Article 11 | Technical documentation | SOC 2 Type II system description, this document, and the GDPR and data processing pack. Deployment-specific configuration is recorded during implementation. | SOC 2 Type II report |
| Article 12 | Record-keeping and logging | Every agent action is logged. Prompts and prompt templates are versioned; model weights we train are managed through a model registry, so a result is back-traceable and reproducible within the tolerance non-deterministic models allow. | AI/ML Policy; Logging and Monitoring Policy |
| Article 13 | Transparency toward deployers | Published security documentation, this correspondence document, and the SOC 2 Type II report available under NDA. Agent behaviour, approval thresholds, and connected systems are documented per deployment. | Security page; SOC 2 Type II report |
| Article 14 | Human oversight | High-risk and sensitive operations route to a human intervention workflow before execution. Which operations qualify is configured per customer during implementation: margin floors, discount thresholds, spend limits, and which records an agent may write to. | AI/ML Policy |
| Article 15 | Accuracy, robustness, cybersecurity | Agents run on dedicated service accounts under least-privilege RBAC, included in periodic access reviews. Input controls enforce strict data boundaries to mitigate prompt injection and adversarial input. Outputs are rate limited. Underlying security controls are SOC 2 attested, with annual independent penetration testing and defined vulnerability remediation timeframes. | AI/ML Policy; SOC 2 CC6, CC7; Vulnerability Management Policy |
| Article 17 | Quality management system | Twenty-six documented policies with named owners, versions, and scheduled renewal dates, monitored continuously through a GRC platform. Documented SDLC with peer review, segregation of duties, and separated development, test, and production environments. | SOC 2 CC5, CC8; policy set |
| Article 72 | Post-market monitoring | Continuous platform and agent monitoring with alerting on anomalous access and failed policy checks. Workflow results and user feedback are captured to support ongoing refinement. | SOC 2 CC4.1, CC7.2; SOC 2 system description |
| Article 73 | Serious incident reporting | Documented incident response plan with severity classification, mandatory internal reporting within 24 hours, containment for critical and high incidents, and direct notification of affected customers without undue delay. | Incident Response Plan; Breach Notification Policy |
What ships with a deployment
- A configuration record of which agents run, which systems they connect to, and which operations require human approval.
- An audit trail of agent actions, available to you.
- Access to the SOC 2 Type II report and HIPAA attestation under NDA, plus a penetration test summary and the subprocessor list.
- This document and the GDPR and data processing pack.
InstaLILY builds and deploys a solution for each customer. Approval thresholds, model selection, connected systems, and the placement of the deployment are set during implementation rather than fixed in the product, so the documentation above describes your configuration, not a generic one.
What this document does not claim
- It is not a declaration of conformity, and there is no CE marking or notified-body assessment behind it.
- InstaLILY does not hold ISO/IEC 27001 or TISAX. Neither has been scoped. Our independent assurance is a SOC 2 Type II report covering the security criteria and a HIPAA attestation.
- Where a deployment is high-risk under Annex III, the conformity assessment, registration, and post-market obligations are real and are not discharged by this document. We will work through them with you.
- Nothing here is legal advice, and it is not a substitute for your own assessment of your use of the platform.
Questions about anything in this document go to hello@instalily.ai. We would rather answer them before procurement than during it.
GDPR and data processing packDescription of processing, technical and organisational measures, subprocessors, and international transfers.