Dlever_os
--:--

Technologydlever

Applied artificial intelligence

We use AI in the stretch of a process that needs interpretation (reading a document, understanding an email, drafting a paragraph from some data), and only in that stretch. Everything else remains deterministic automation: cheaper, faster and easier to audit.

00The need

Some stretches of a process require reading and interpreting: a document that arrives as a PDF, an email that has to be understood, a text that has to be drafted from some data. Until now a person did that, and that is exactly where AI adds value, if it is used with limits.

A good fit if…

  • Someone reads documents to pull data out of them
  • Repetitive texts are drafted from data
  • You want to use AI without losing control of what it does

01Extractor, not autonomous agent

The difference is not one of technology: it is one of design. We give it a specific stretch and clear limits, not the whole process.

An autonomous agentHow we use it
  1. What it receivesA goal, and it decides what to look for
  2. If the data isn't thereIt fills in the most likely answer
  3. If it doesn't succeedIt keeps trying until something comes out
  4. When auditing itHard to tell at which step it went wrong
  1. What it receivesThe source, and which data to pull from it
  2. If the data isn't thereIt returns empty
  3. If it doesn't succeedLimited retries, then a person decides
  4. When auditing itThe output follows a defined schema

Key idea

If the process can be solved with fixed rules, AI isn't needed.

02What we use it for

Two uses, both on documents, and both with AI placed inside a flow that validates what it returns.

  • Structured extraction

    Pulling data out of a document

    Invoices, delivery notes, work reports: AI extracts the fields and the flow validates them before saving.

  • Document generation

    Assembling a document from a template

    AI drafts only the parts that require interpretation, and the rest is assembled deterministically.

Key idea

Never on its own: always inside a flow with rules.

03How we make it reliable

Four rules, the same in every flow we build.

  1. Defined output schema

    The response always has the same shape, and the rest of the flow knows what to expect.

  2. Empty when there is no data

    If the data doesn't appear in the source, it returns empty: it doesn't infer or approximate it.

  3. Limited retries

    A limited number of attempts, not a loop until something comes out.

  4. Escalation to a person

    What can't be resolved with confidence goes to someone who decides.

Key idea

Reliable doesn't mean infallible: it means that when in doubt, it alerts.

04Which models

We are not tied to any one model. The one used in each process is chosen for what that process requires (cost per run, extraction quality, data limits), and it can be swapped without rebuilding the flow.

Key idea

The model is one more piece, not the center of the system.

First step

We come to your offices to learn about your case

No cost, no commitment, and no catalog presentation. We see the process where it happens and talk with the people who run it. You come away with a reading of your situation and a first prioritization.

Request a visit