Most companies treat compliance as a last-minute checklist. We built a SaaS platform that turns your product documents into a structured, regulation-by-regulation picture of exactly where you stand — and what needs to change.
Your team collects datasheets, legal texts and internal checklists across spreadsheets, emails and shared folders. When a regulation changes — or an audit arrives — nobody has a single, reliable picture of where each product actually stands.
Datasheets, emails and checklists spread across systems with no single source of truth.
Every time a regulation updates, the work starts over from scratch.
Compliance, product and legal teams work from different versions of the same reality.
Drop in your datasheets and technical product files.
A large language model (LLM) compares your documents against each individual article and proposes an assessment.
See gaps, override assessments, track progress over time.
Each one is modelled article by article, not as a generic checklist. Adding a regulation doesn't change how your team works.
Material requirements, recycled content, recyclability, minimisation and labelling — assessed against your packaging technical files.
Essential cybersecurity requirements for products with digital elements, plus the Article 14 reporting duties that apply from 11 September 2026.
Declarations of conformity along the whole supply chain — including when the finished article is made for you by a third-party manufacturer.
Risk class, requirements for high-risk systems and transparency obligations — applicable since 2 August 2026.
From 12 August 2026 the requirements of Regulation (EU) 2025/40 apply to packaging placed on the EU market. Some obligations — recycled content targets and harmonised labelling among them — follow later dates, but the technical documentation behind them is needed well before that.
Article 14 of the Cyber Resilience Act applies more than a year before the rest of the regulation. From that date, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents to their coordinating CSIRT and to ENISA — on a timetable measured in hours, not weeks.
Reporting obligations start on this date. The remaining obligations of Regulation (EU) 2024/2847 — including the essential requirements and CE marking — follow on 11 December 2027.
An actively exploited vulnerability or severe incident must be flagged within 24 hours of becoming aware of it.
A full notification follows within 72 hours, with the corrective and mitigating measures taken or planned.
For vulnerabilities, a final report is due within 14 days of a corrective measure being made available.
Meeting Article 14 is not really a reporting problem — it is a preparation problem. When the clock starts, you need to already know what the product contains, which requirements applied to it, and who signed off on what.
For the CRA you do not upload code to us. A workflow is installed in your repository — we set it up, or you add it by hand — and the platform runs it on request. The analysis happens there; only its result comes back to us.
Regulation (EU) 2024/1689 applies in stages, and the stage covering most products has just begun. If your product carries an AI system — even a single feature — the first question is not how to comply, but which risk class you fall into.
From this date the obligations for high-risk systems listed in Annex III and the transparency requirements of Article 50 apply. The prohibitions have applied since 2 February 2025 and the general-purpose model obligations since 2 August 2025; high-risk systems under Article 6(1) — those embedded in products already covered by sectoral legislation — follow on 2 August 2027.
The AI Act does not put the same obligations on everyone. Between a high-risk system and one subject only to transparency duties lies the difference between a full technical file and a line of disclosure. Getting the classification wrong is expensive in both directions.
Under Regulation (EC) No 1935/2004, the operator who places a food contact material on the market answers for it — even when someone else made it. If you buy the finished article from a converter who also sources the substrate, inks, adhesives and coatings, your compliance rests entirely on the declarations that come up the chain to you.
When your supplier both buys the materials and makes the article, you never see most of the evidence behind it. The platform reads the declarations of conformity you do receive and tells you what they actually cover — and what they leave open.
Every feature is designed around how compliance work actually happens.
Each requirement is assessed individually, so you know exactly which articles are covered and which aren't.
A large language model produces the initial assessment for each article. Your team confirms it or corrects it — the final version is always the human one.
The technical file and declaration of conformity are generated directly from the analysis, ready for submission.
Every change, override and annotation is logged with timestamp and author.
Multiple users in the same organisation share one live compliance view.
The same workflow applies to any EU regulation, not just the one you're working on today.
Regulations aren't written to create paperwork. They encode what the market, regulators and society expect from your products. When you can see exactly which requirements you're missing — and why — compliance stops being a burden and starts being a development brief. That's what we built this for.
We started with the EU Packaging and Packaging Waste Regulation. The beta now also covers the Cyber Resilience Act — including the Article 14 reporting duties that apply from 11 September 2026 — the AI Act, applicable since 2 August 2026, and food contact materials, with particular attention to articles made for you by third-party manufacturers. Other EU regulations follow the same workflow.
Apply for beta access
"With Conformity Guru we finally understood what compliance with FCM and the PPWR actually required of us — not a generic checklist, but which requirements were uncovered, and why."
We're in beta. A small group of compliance teams are already using the platform — and telling us what to fix.
The platform works. You can upload documents, run analyses and see results today. Some features are still being refined, and we actively involve beta users in shaping what comes next.
No. Conformity Guru is a SaaS platform: it runs in your browser, there is nothing to install or maintain, and updates — including new regulations and revisions to existing ones — arrive without you doing anything. The one exception is the CRA, where a workflow is installed in your repository, because that is the only way to analyse the code without it leaving your own infrastructure.
No. You can upload standard product documents — datasheets, technical files, specification sheets, supplier declarations. The platform handles the rest.
Four, today: the Packaging and Packaging Waste Regulation (PPWR), the Cyber Resilience Act (CRA), the AI Act and the food contact materials framework (FCM). The architecture is regulation-agnostic — we expand the library based on what beta users are actually working on.
Scope is the first thing the platform assesses. The CRA covers products with digital elements placed on the EU market, with a stricter regime for the important and critical categories. If your product is out of scope, you get that answer with the reasoning behind it — which is itself worth documenting.
It changes where the evidence lives, not who is responsible. If you place the product on the market under your name, the obligations are yours. This is exactly the case the food contact materials support was designed around: the platform works from the declarations and technical documents your manufacturer supplies, and tells you where they fall short of what you need.
You can invite team members and assign them to your organisation's workspace. Everyone shares the same compliance view in real time.
The platform uses a large language model for the first pass: it reads the documents you upload and compares them against the text of each individual article, proposing an assessment for each one. That is not the last word — every assessment can be confirmed or corrected by your team, and what ends up in the technical file and the declaration of conformity is the version you approved, with a date and an author.
Yes, and the answer does not change with the kind of data. The documents you upload are held in an encrypted database with row-level security: access to each document is limited to the authorised people in your organisation, and the isolation is enforced by the database itself rather than by application logic. Inference runs on a selected European provider under zero data retention: whatever we pass to it — code or documents — is not kept there. And we don't use your data to train models.
In two different places, and that is a product decision rather than a security one. Source code never reaches our servers: it is analysed by a workflow running in your own repository, and only the result comes back to us — never the files. Product documents we do keep, because they are needed: the platform maintains their history — the analysis has to be re-run at every product revision and every regulatory update — and the technical file is composed from those documents.
Join the beta. Upload your first product document and get a structured compliance picture in minutes. No commitment, no sales call required.