AI document review and drafting for design and quality teams.
Andrei writes to your procedure's own structure and then checks the draft against it, requirement by requirement. Design verification, risk files, test method validation, CAPA, and the transfer package that has to hold together at the end.
The device was fine. The file couldn't prove it.
A verification report that references acceptance criteria instead of restating them. A CAPA that names an operator instead of the process that let the defect through. A trace matrix with results nobody can tie back to a requirement. None of this is a design problem. All of it is what an inspector reads, and it is where two thirds of device findings land.
Source: FDA warning-letter statistics on medical devices, fiscal year 2025 (1 October 2024 – 30 September 2025). Cost-of-quality figures for the sector are on the home page.
Bring the document type and the procedure behind it.
There is no fixed catalogue. Andrei learns a document type from your procedure and your approved examples, so a new one takes a conversation, not a release. These are where device teams usually start.
Design controls
The part of the file that 25 of 44 FY2025 warning letters had something to say about.
- Design and development plansPhases, deliverables, reviews, and who approves what, written so the plan can actually be closed against later.
- User needs and design inputsRequirements that are measurable, testable, and traceable, with the ones nothing could ever verify flagged while there is still time.
- Design outputs and specificationsOutputs tied back to the inputs they satisfy, so the trace matrix is a record rather than a reconstruction.
- Design reviews and DHF completenessReview records that say what was decided, and a file checked for the deliverables the plan promised.
- Traceability matricesParsed as structured tables, so Andrei can name the requirements with no result and the results with no requirement.
Risk and test methods
Where a weak document is invisible until verification cannot close.
- DFMEA and PFMEAYour own form and scoring scale, with controls that agree with the risk file they feed and a conclusion the scores support.
- Risk management fileHazards, sequences of events, and risk controls kept consistent with each other across the ISO 14971 lifecycle.
- Test method developmentMethod descriptions detailed enough that a second engineer would run the same test the same way.
- Test method validationTMV and measurement system analysis reports, with sample size and acceptance criteria stated rather than implied.
- Sampling rationaleThe sampling plan, the SOP it came from, the level, and the acceptance number — the four facts reports most often leave out.
Verification, validation and transfer
Protocols and reports written months apart that still have to agree.
- Design verificationProtocols and reports where each section restates the criterion it claims to meet, and the conclusion follows from the results in the body.
- Design validation and usabilityValidation against user needs, including use-related risk and the usability file that has to support it.
- Process validationIQ, OQ, PQ protocols and reports, process characterization, and the limits the PQ was actually run to.
- Design transferTransfer packages checked for the released documents they depend on across process development, packaging, and manufacturing.
- Equipment qualificationQualification reports tied to the acceptance criteria of the protocol they close.
Quality events and post-market
The most-cited findings of FY2025, both of them in this column.
- CAPA and non-conformancesInvestigations that reach a system-level cause, with actions traced to the causes they close and effectiveness criteria set before approval.
- Complaint handlingIntake, evaluation, and a reportability decision with the rationale written down rather than assumed.
- Change controlImpact assessments covering design, process, risk, and regulatory consequences, including whether the change is a letter-to-file.
- Supplier qualitySupplier evaluations, incoming decisions, and the evidence behind an approved-supplier list that has to survive an audit.
- Post-market surveillanceSurveillance plans and periodic reports, including the EU MDR documents that have to reconcile with your complaint data.
What the five weeks actually look like.
A design verification report, from the requirement matrix to the signature. Andrei never approves anything — the decisions stay where they have to stay.
Requirements
The requirement matrix goes in as a table, not as prose. Andrei checks each requirement is measurable and testable, and names the ones nothing could close against — while changing them is still cheap.
Andrei checksMethod and sampling
Before any results exist, Andrei asks for the test method, its TMV status, the sampling plan, the SOP the plan came from, the level, and the sample size rationale. These are the facts reports get written without and get returned for.
Andrei asksResults
Raw data, equipment IDs, and lot identification go in as attachments. Andrei reads them and cites the page a number came from, so a reviewer can check a claim without reopening the folder.
Andrei draftsDraft
Andrei writes the sections in your template's order and restates each acceptance criterion inside the section that claims to meet it, instead of pointing at §4.2 and hoping.
The engineer decidesCheck
Every requirement gets a traffic light and a stated reason. Amber and red come with a suggested edit you can apply, reword, or dismiss.
Andrei checksReview and approve
The reviewer comments, returns it with feedback, or approves it. Approval is an electronic signature in a tamper-evident hash chain, and the report exports as DOCX in your own template.
The manager decidesAndrei checks your procedures. These are what your procedures implement.
A report is compliant because it satisfies the procedure your company approved, not because it matches a regulation in the abstract. Andrei works from the procedure. Knowing what sits behind it is how it asks the right follow-up question.
21 CFR Part 820
The quality management system regulation, incorporating ISO 13485:2016 by reference since 2 February 2026.
820.30 design controls
Inputs, outputs, review, verification, validation, transfer, changes, and the design history file that holds them.
820.100 and 820.198
Corrective and preventive action, and complaint files — the two most-cited device findings of FY2025.
ISO 13485:2016
The quality management system your Part 820 obligations now run through, and most of the world already used.
ISO 14971:2019
Risk management across the device lifecycle, and the file every DFMEA has to stay consistent with.
IEC 62366-1
Usability engineering, and the use-related risk that design validation has to answer for.
IEC 62304
Software lifecycle processes, where verification evidence has to match the safety class you claimed.
Regulation (EU) 2017/745
Technical documentation, clinical evaluation, and post-market surveillance that has to reconcile with your complaint data.
21 CFR Part 11
Electronic records and signatures: attribution, audit trail, signature manifestation, record integrity.
Andrei is not a regulatory database and does not give regulatory advice. It reads the procedure you give it and checks whether the document in front of it satisfies that procedure. Your quality and regulatory experts decide everything that matters.
An AI-assisted file still has to survive an audit.
Which means the assistance has to leave a trail of its own. Who wrote a sentence, when, on what evidence, and who approved it.
Traceability that holds up
Requirement to method, method to result, result to conclusion. Andrei reads the chain as a chain, so a break in it is something you are told about rather than something an auditor finds.
Every edit attributed
Who wrote a sentence, when, and on what evidence. Nothing is silently overwritten, and the history of a section is still there when someone asks how a number changed.
Signatures that detect tampering
Approvals are recorded as electronic signatures in a hash chain, so a record altered after approval is a detectable record, not a quiet one.
Questions device teams ask first.
Does Andrei replace our eQMS?
No. Andrei is not a quality management system and does not try to be the system of record. Your DHF, CAPA records, and change orders keep living where they live today. Andrei is where the document gets written and checked before it goes back into that system, and it exports into the same Word template your procedure already specifies.
How does Andrei learn our verification template?
You give it the procedure and two or three approved reports. Andrei derives the section structure and the criteria from those, so a report written to SOP-QA-014 is judged against SOP-QA-014 and not against a generic idea of what verification looks like. When the procedure is revised, the criteria follow it.
Can it handle requirement traceability matrices?
Yes. Matrices are parsed as structured tables rather than flattened into prose, so requirement IDs, acceptance criteria, methods, and results stay linked. Andrei can tell you which requirements have no result, which results have no requirement, and where a result contradicts the criterion it is filed under.
What changed for us under the QMSR?
Part 820 now incorporates ISO 13485:2016 by reference, and FDA began inspecting against it on 2 February 2026. In practice the documentation expectations did not soften: design controls and CAPA were the two most-cited findings in FY2025, and both survive the transition. What matters is that your procedures reflect the new structure — and Andrei reads whichever version of them you give it.
Can a reviewer see why Andrei flagged something?
Every judgment comes with a stated reason tied to the criterion and the section it was read from. A reviewer can disagree in one click, and disagreements are visible rather than silent. Nothing is flagged on a hunch the reviewer cannot inspect.
Is anything approved by AI?
No. Andrei drafts, checks, and suggests. A named person edits, reviews, and signs, and the approval is recorded as an electronic signature. Risk classification, validation strategy, and transfer readiness are decisions your engineers make.
Try it on a report you have already approved.
Send us one finished verification report and the procedure it was written against. We will show you what Andrei would have flagged, and you can judge whether it is right. We reply within one business day.