Shipper

Shipper is an on‑prem B2B AI co‑pilot that reads tech contracts (DORA), maps vendor risks and impact, and cuts review from hours to 30 minutes via LLM, RAG and graph tech.

Comment

Inspiration

European financial institutions are racing to comply with new rules that force them to prove they can survive outages and cyber incidents, not just tick compliance boxes. DORA is one of the strictest examples: it requires banks and insurers to understand exactly how their critical services depend on hundreds of third‑party ICT providers and contracts. Talking to industry contacts and reading recent surveys, we saw two things: many firms still aren’t ready, and DORA programs can easily cross €1m in total cost for large institutions. Most of that money goes into manual work: lawyers, risk teams and IT staff reading dense contracts, pasting text into spreadsheets, and emailing each other to figure out “what breaks if this provider fails?”

We built Shipper because that felt like the perfect job for AI plus graphs, not more spreadsheets.

What it does

Shipper is an on‑prem B2B AI co‑pilot for financial institutions:

  • It reads ICT and vendor contracts, pulls out the key clauses, and flags risks and gaps.
  • It maps those contracts onto a graph of vendors, systems, and services, so you can see the “blast radius” if a provider fails or a contract changes.
  • It uses retrieval‑augmented generation to answer questions like “Which contracts expose us on this requirement?” with citations back to the exact clauses and regulatory text.

For a typical large institution, Shipper cuts review from several hours to about 30 minutes per contract and can save six figures per year in internal effort on contract work alone.

How we built it

We designed Shipper around three core pillars:

  1. AI contract understanding

    • We use a hosted Cerebras GPT‑OSS‑120B model for clause extraction, classification, and risk reasoning.
    • A small parsing pipeline takes raw contract text (PDF/Word) and has the model output structured JSON: parties, services, SLAs, security/incident clauses, termination, and DORA‑relevant obligations.

  2. RAG over regulation and policies

    • We built a retrieval layer over DORA legal text, RTS/ITS guidance, and internal policies so the model never answers in a vacuum.
    • For each contract, Shipper queries this corpus to map clauses to obligations and highlight where the contract is weak or silent, returning answers with citations to both the source document and the relevant regulation.

  3. Third‑party dependency graph

    • We model third parties, contracts, services, systems and obligations as nodes and relationships in a graph database (Neo4j)
    • Every time the AI processes a contract, it updates the graph: who provides what, to which system, under which clauses.
    • The frontend uses a graph visualization library to let users explore dependencies and see “what breaks” if they remove a vendor or a service.

On top of this, we added a agentic workflow: when a user uploads a contract, an orchestrator runs the steps in sequence—ingest → parse → update graph → generate explanations and answers—so the experience feels like a single, intelligent assistant rather than many separate tools.

What we learned

  • Regulation is graph‑shaped. Once we started modelling DORA obligations, third‑party vendors and systems, it became clear that a graph is more natural than rows and columns. Impact analysis and “what‑if” questions become single queries instead of multi‑sheet Excel puzzles.
  • RAG beats “just a big model” for compliance. Grounding the model in real text, with citations, is essential for trust and auditability, especially in regulated environments.
  • Enterprise constraints matter. On‑prem deployment, data residency, audit logging, and access control add real design constraints, but they also make the product more credible for banks and insurers.

Challenges we faced

  • Balancing complexity with demoability. The real compliance problem is messy—multiple teams, multiple systems, and nuanced regulations. We had to decide what to simulate vs. what to actually implement to have a compelling demo within hackathon time.
  • LLM prompt design for contracts. Contracts are long, repetitive, and formatted badly. We iterated a lot on chunking strategies, retrieval prompts, and JSON schemas to reduce hallucinations and get consistent structured outputs.
  • Graph schema design. There are many ways to model vendors, systems and obligations. We spent time converging on a schema that is expressive enough for real‑world use, but simple enough to power fast queries and visualizations in a prototype.
  • On‑prem mindset in a cloud hackathon. We wanted Shipper to look and feel like something a bank could actually install behind its firewall, which influenced how we thought about configuration, secrets, and not hard‑wiring everything to a single SaaS.

Overall, Shipper taught us how to turn a very abstract regulation into a concrete AI product with a clear user story and measurable ROI.

(we have provided v1 and v2 in the "Try Out Links", the related github branches dev-romain and bogdan)

Built With

Share this project:

Updates