Skip to content

We built it ourselves

Review of an AI implementation you built yourself

Someone on your team set up an agent in Claude Code, n8n, or Make. It works until it breaks. We verify what happens when it stops, what to keep, and what to rebuild.

  • Steps: 4
  • Read time: 5 min
  • Questions: 4

We do not tell you to scrap what you already have. An internal deployment is a strong starting point: your company knows what it needs and already has a working prototype. The review addresses questions no one asked during the build phase because they were not needed yet.

Out of 344 verified corporate AI incidents between 2023–2026, 188 cases involved damage caused directly by the system without an external attacker. The pattern repeats: the agent was granted database write access during development, and no one revoked it for production.

In July 2026, a coding agent connected to a production database ran a live migration within ten minutes. In another documented case, deleting the database along with its backups took nine seconds.

What breaks in self-built deployments

Development permissions remain in production

The agent has full write access to the database, inbox, or CRM because it was convenient during testing. Revoking write access and introducing human approval is usually the first fix.

A backup that no one has restored

The backup exists in the settings. No one has verified whether it can be restored or how long it takes.

API keys in code, in a spreadsheet, or in chat

Model keys and accounting system keys in a single file visible to anyone with repository access.

No logs

No one can tell what the system sent last Tuesday and to whom. Without this, handling complaints or inquiries is impossible.

"Works" means "worked on three examples"

No test suite, so every prompt change or model update is tested live on customers.

Chatbot without disclosure that it is AI

Starting 2 August 2026, an obligation under Art. 50 of the AI Act. Applies to website bots, voicebots, and inbox assistants if they respond to customers.

Model provider missing from the processing register

Customer data goes to an external API, with no mention of it in the record of processing activities or data processing agreements.

Close-up of brass gears, one tooth cracked, thin gold scratch
Next, step 02How the review works

How the review works

  1. Day 1: briefing and configuration accessWho built it, what it should do, where it runs, what keys it holds. Configuration access, never customer data.
  2. Days 2–3: twelve-point checklist reviewThe exact list published below. Each item receives one of three ratings: keep, fix, rebuild.
  3. Day 4: report with cost estimates for every itemWhat stays, what gets fixed, what requires a rebuild, and what each item costs. The report is yours, regardless of who executes the fixes.
  4. Days 5–10: fixes (optional)Typically permissions, secrets, backups, logs, and a test suite. Documentation is built from scratch, as self-made deployments lack it.
Large magnifying glass over a small automation blueprint drawn in gold lines, several weak points marked in orange
Next, step 03A checklist you can run yourself

A checklist you can run yourself

Twelve questions. If the answer to more than three is "I do not know", an audit is necessary. If all are "yes", you do not need one and should not pay for it.

  1. Does the agent have a dedicated account with minimal permissions?Not the account of the employee who deployed it.
  2. Does writing to production require human approval?Sending an email, issuing an invoice, modifying the CRM, deleting anything.
  3. Has anyone restored a backup in the last month?Restored, not just "enabled".
  4. Where are the API keys stored, and who can view them?If the answer starts with "in a file", you have your answer.
  5. Is every system action logged?With timestamp and payload, so you can trace a complaint from last week.
  6. Who runs the test suite after every change?At least thirty cases, including edge cases.
  7. What happens when the vendor updates the model version?Versions are deprecated every few months. Who tracks this, and who validates outputs after the update?
  8. Does the user know they are speaking with AI?Customer or employee. Art. 50 AI Act, from August 2, 2026.
  9. Is the model provider in the record of processing activities?Along with a data processing agreement. Applies to every external API receiving personal data.
  10. Who responds when something goes down at 7:00 AM?First and last name of the person responsible for the system, not "IT department".
  11. Have system users completed documented training?Art. 4 AI Act: syllabus, participant list, materials.
  12. What is the monthly system cost, and who sees the invoice?API invoice spikes are the most common surprise after the third month.
Pad with twelve fields, four marked with a gold checkmark, next to a key and padlock
Next, step 04What usually stays, what needs a rebuild

What usually stays, what needs a rebuild

Stays as isWe refineBuilt from scratch
Process logic and tool selectionPermissions and dedicated accountsAI acceptable use policy
Tested prompts and configurationVault for keys and secretsCompany AI system inventory
Integrations that workBackups with restore testingTest suite
Builder as process ownerActivity logsArticle 50 disclosure notices
Three crates on a conveyor belt: one sealed with a gold band, one open with tools, one disassembled into parts
These are all the stepsFrequently asked questions and next steps

Questions and answers

Frequently asked questions

We built an agent in Claude Code and it works. Why do we need an audit?

To verify what happens when it fails or takes an action no one intended. The review assesses permissions, backups, keys, logs, test suites, and documentation, not the prototype itself. If you can answer yes to all twelve checklist questions, you do not need an audit.

Does an audit mean rebuilding everything from scratch?

No. Process logic, prompts, and working integrations usually remain untouched. Permissions, secrets, backups, and logs get fixed. Documentation is created from scratch, as self-built deployments rarely have it.

How long does the review take and how much does it cost?

Four business days to deliver the report: one briefing call, two days of auditing against our twelve-point checklist, and one day to prepare the report with cost estimates for every fix. Pricing is set after the initial call, based on the number of systems. The report is yours, regardless of who implements the fixes.

Do we have to grant you access to client data?

No. The review only requires access to configurations, permissions, and logs, not the data contents. Where behavior must be verified on sample data, we work on duplicates or anonymized datasets.

Other paths

What next

No-obligation call

Review in four business days

An interview, two days following a 12-point checklist, a report with the cost of every fix. Start with a 30-minute call to tell us what is stalled and where.