The workflow
How AI contract review works
Six steps from upload to sign-off. The system handles the first five, against the firm’s own standard positions. The sixth it deliberately leaves alone.
Step by step
The six steps, up close.
Each step says what it means for the firm’s day-to-day work.
Upload
The firm uploads a Hungarian-language contract as PDF or DOCX — in the form the file already arrives in. The document goes into the private EU environment, or onto the firm’s own server; it never reaches an external AI provider.
What that means in practice
- No re-typing: the existing file goes in, unchanged.
- The uploaded document stays in the private environment, with no external AI API.
Clause extraction
The system reads the contract end to end and pulls out what matters legally: the parties, the obligations, the term, the liability and termination clauses, and the GDPR provisions. Provisions scattered across dozens of pages become one structured, reviewable picture.
What that means in practice
- Clauses appear in one place, in comparable form.
- A provision buried in an annex does not get missed.
Risk flagging
The extracted clauses are measured against the firm’s own standard positions — the playbook — rather than a generic checklist. The system flags where the wording departs from what the firm normally accepts, and just as importantly, flags the protective clause that is missing altogether.
What that means in practice
- Deviations are shown against the firm’s own expectations, not an abstract standard.
- A missing clause is as visible as a badly drafted one.
Drafting suggestions
For each flagged point the system proposes a redline and standard clause wording in the firm’s own drafting voice. A suggestion stays a suggestion: it does not overwrite the document and it does not decide anything on the lawyer’s behalf.
What that means in practice
- The starting text is ready — drafting does not begin from a blank page.
- Every suggestion can be accepted, rewritten or discarded.
Question and answer
The firm can put questions to the document — what is the notice period, where does the contract cap liability, what does it say about data processing — and the answer comes back with a citation to the specific clause. Because of the citation the answer is checkable: it does not ask for trust, it shows its source.
What that means in practice
- Every answer carries the clause it came from.
- Verifying takes a glance, not a re-read of the contract.
The lawyer finalises
This step the system deliberately does not take. Professional review, the decision and the responsibility remain with the acting attorney — AI Szerződéselemző is software, not legal advice. What the first five steps produce is preparation; the lawyer takes it from there.
What that means in practice
- The output is prepared material, not a legal position.
- The firm answers to the client — the system does not change that.
And where does all of this run? Not at a US provider.
All six steps run on private AI: on ATAILA’s own EU hardware, or entirely on the firm’s own server. There is no external AI API in the pipeline, so privileged material never leaves the protected environment. A DPA, an audit trail and data export are part of the package.
The playbook
This is what makes the output the firm’s own.
The playbook is an ordered record of the firm’s standard positions: the few dozen clause expectations the partners already carry in their heads, simply never written down. It is the yardstick for step three — without it, risk flagging would stay generic.
What it holds
The liability cap the firm normally insists on, the penalty and termination terms it can live with, the data-protection clauses it treats as mandatory — in short, what the firm expects to achieve in a given contract type, and what it will not accept.
Configured once
Capturing the standard positions is one-off work per contract type; from then on every processed document is measured against it. It can be changed at any time, and the next contract already uses the updated version.
Why it is not generic
Without a playbook any tool can only produce an abstract list of risks. With one, each flag speaks to the firm’s own expectation — which is what makes it usable, and what makes it quick to judge whether the flag is fair.
Capturing the playbook is the first real step of any rollout, and part of the pilot. How the pilot runs →
Focus
Why we start with a single contract type
Because “all of law” cannot be measured, whereas an NDA or a service agreement can. Starting narrow is not modesty — it is the only way the firm actually sees what it is getting.
One type, measurable result
For a single contract type you can say precisely what should have been surfaced and what the system actually flagged. The firm sees the result on its own files, in a form it can hold to account — not a general promise.
The playbook stays finite
The standard positions for one contract type can be captured in a few hours with an experienced colleague. Across a whole practice area the same exercise would run into months and never quite finish.
Work first, breadth second
Once the first type reliably delivers, the next one builds on a routine that already exists: upload, flag and review are settled, and only the positions grow.
The platform keeps growing
Contract review is the first module.
The same six steps — upload, extract, flag, suggest, cite, and the lawyer’s sign-off — are the foundation of the modules that follow. All of them run on the same private AI platform:
- GDPR and EU AI Act compliance assistant
- Document and template generation
- Due-diligence support
- Legal Q&A on Hungarian law
- Client intake
Let us walk the six steps on your contract.
Tell us which contract type eats the most time in your firm, and we will show you the whole workflow on it — against your own standard positions.