142 tools en géén governance — waarom de populairste AI-engineering toolkit het belangrijkste vergeet

De AI Engineering Toolkit — met 3.143 sterren en 577 forks op GitHub — is een van de populairste curated lists in het LLM-ecosysteem. De repo bundelt 142 tools in veertien categorieën: van vector databases tot agent frameworks, van fine-tuning tot structured generation. Het is de go-to landkaart voor AI-engineers die productie-LLM's bouwen.

Maar wie de lijst aandachtig leest, ziet dat er één categorie volledig ontbreekt. En dat die afwezigheid meer zegt over de staat van AI-engineering dan de 142 tools die wél genoemd worden.

Wat er wél in staat (en waarom dat waardevol is)

De toolkit is opgedeeld in 14 inhoudelijke categorieën. De breedte is indrukwekkend:

Categorie	Aantal tools	Wat DjimIT ervan gebruikt
Data Collection & Web Scraping	33	Firecrawl, Crawl4AI, Playwright
Agent Frameworks	21	CrewAI, LangGraph, Pydantic AI
LLM Training & Fine-Tuning	14	unsloth, Axolotl, torchtune
Evaluation & Testing	13	Langfuse, DeepEval, Opik, Phoenix
PDF Extraction	11	PyMuPDF (in dagelijks gebruik), Docling
RAG	11	Qdrant (staat bij Vector DBs), txtai
Orchestration & Workflows	9	DSPy, Dify, Langflow
Local Development & Serving	9	Ollama, LiteLLM, llama.cpp — core stack
Vector Databases	8	Qdrant — primaire vector store
LLM Inference Platforms	8	Groq, OpenRouter
AI App Frameworks	8	Gradio, Streamlit
Model Management	5	Hugging Face Hub, MLflow
LLM Safety & Security	4	Guardrails, NeMo, Garak, DeepTeam
Structured Generation	3	Instructor, Outlines, Guidance

De lijst is actueel, breed gedragen, en de keuze voor MIT-licentie maakt de repo vrij te gebruiken. Voor discovery en oriëntatie is dit een ijzersterke bron. Maar daarmee is meteen alles gezegd: dit is een catalogus, geen operating model.

De catalogus-paradox

De titel "toolkit" schept een verwachting die de inhoud niet waarmaakt. Een echte engineering toolkit bevat runnable code, referentiearchitecturen, een decision framework, CI/CD-integraties, en deployment blueprints. Deze repo bevat: een README. 32 commits. Geen releases. Geen configuratie. Geen tests.

Dat maakt de repo niet waardeloos — integendeel. Maar het verandert de gebruikswijze fundamenteel. De repo is een oriëntatieinstrument, geen implementatiekompas. Een atlas, geen routeplanner.

Het gevaar schuilt in het catalogus-effect: een overvloed aan keuze zonder keuzecriteria. Alle 142 tools staan als gelijkwaardig naast elkaar. Dat creëert tool sprawl, geen versnelling. Wie deze lijst als adoptielijst gebruikt, adopteert chaos — niet architectuur.

Wat ontbreekt: de 15e categorie

De meest veelzeggende omissie is geen tool — het is een complete categorie. Er is geen enkele kolom voor:

• Governance & compliance: geen BIO2, NIS2, ISO 27001, EU AI Act
• Enterprise maturity scoring: geen onderscheid tussen prototype-grade en enterprise-grade
• Security posture: OWASP LLM/Agentic threats, supply chain attestation, runtime controls — niets
• Cloud sovereignty: data residency, vendor lock-in, exit-strategie
• Lifecycle governance: model registry, deprecation policies, exception management
• Auditability: immutable logs, trace IDs, compliance evidence

De "LLM Safety and Security" categorie telt vier tools — allemaal technisch (Guardrails, NeMo Guardrails, Garak, DeepTeam) en geen enkele governance-gericht. Vier tools op 142. Dat is 2.8%.

Wat de community "AI engineering" noemt, is in de praktijk: tool selectie zonder governance, ontwikkeling zonder security baseline, en deployment zonder compliance evidence. Dat is precies het gat waarin DjimIT opereert.

Van catalogus naar controlled catalog

De operationele vraag is niet "welke tool moet ik kiezen?" maar "hoe maak ik van deze lijst een governed enterprise asset?" Daarvoor zijn vijf transformatielagen nodig.

Laag 1: Enterprise scoring per tool

Elke tool moet gescoord worden op minimaal acht dimensies:

Dimensie	Vraag
Maturity	Actief onderhouden, stabiel, breed gebruikt?
Security	Security advisories, dependency hygiene, scanning?
Governance	Audit, policies, RBAC, traceability?
Interoperability	Open standaarden, OpenTelemetry, OpenAI-compatible API?
Exit strategy	Migratiepad zonder vendor lock-in?
Runtime cost	CPU/GPU/token/storage/network impact?
Compliance fit	GDPR, EU hosting, data minimization?
Operational complexity	Hoeveel beheerlast?

Vervolgens classificeer je elke tool: approved, experiment, restricted, of deprecated.

Laag 2: Drie golden paths

Uit de catalogus filter je drie goedgekeurde referentiepaden:

Path A — Local Sovereign AI Lab (wat DjimIT dagelijks gebruikt):

• Ollama of llama.cpp voor inference
• LiteLLM als OpenAI-compatible gateway
• Qdrant voor vector storage
• Docling voor document ingestion
• Instructor of Outlines voor structured output
• Langfuse of Phoenix voor tracing
• DeepEval/Ragas voor kwaliteitsmeting

Path B — Enterprise RAG Platform:

• Document ingestion via Docling/Unstructured
• Vector DB via Qdrant/Weaviate/Milvus
• Orchestration via LlamaIndex of LangGraph
• Eval via Ragas, DeepEval, Giskard
• Observability via Langfuse, OpenLLMetry
• Policy enforcement via gateway
• CI/CD quality gates

Path C — Agentic Workflow Platform:

• LangGraph of Semantic Kernel
• LiteLLM/provider router
• Tool authorization layer
• Human approval gates
• Memory isolation
• Audit trail
• Garak/DeepTeam red-team suite
• OpenTelemetry traces
• Policy-as-code gates

Laag 3: Security baseline

Per implementatie minimaal deze acht controls:

Control	Minimale eis
Identity	OIDC/OAuth2, workload identity, no static long-lived secrets
Tool access	Least privilege, allowlist, explicit scopes
Prompt injection	Untrusted context labeling, tool-call separation
Data protection	PII classification, redaction, retention policy
Logging	No sensitive prompt leakage, trace IDs, tamper-evident audit
Supply chain	SBOM, dependency pinning, provenance checks
Runtime	Sandboxing, rate limits, egress controls
Evaluation	Adversarial tests, regression tests, hallucination tests

Laag 4: Governance operating model

Techniek is noodzakelijk maar niet voldoende. Voor productie vereist elke AI-stack ook besluitvorming:

• AI architecture review board
• Approved tool catalog
• Model risk classification
• DPIA/AIA trigger criteria
• Exception process
• Prompt en agent change management
• Evaluation thresholds
• Incident response for AI failures
• Model/provider exit plan
• Quarterly tool rationalization

Laag 5: Compliance evidence

Tot slot is er de harde eis van bewijsbaarheid. Voor organisaties onder GDPR, NIS2, BIO2 of EU AI Act is "we hebben Guardrails geïnstalleerd" geen volwaardig antwoord op een auditor. Elke golden path moet gemapt worden naar control frameworks: ISO 27001 Annex A, NIST CSF, OWASP Agentic Risks, en de AI Act conformity assessment.

Wat de toolkit onthult over de industrie

De absentie van governance is geen toevallige omissie — het is structureel. De AI-engineering community definieert zichzelf als technisch, en ziet governance als een randvoorwaarde die "er later wel bij komt." Die volgorde is achterhaald.

Wie nu een AI-stack bouwt zonder governance-fundering, herbouwt straks met terugwerkende kracht — tegen drie keer de kosten en met operationele schade onderweg. De volgorde is niet eerst bouwen dan beveiligen. De volgorde is: security baseline → golden path → governed adoption.

De 142 tools in deze catalogus zijn geen blauwdruk voor een productieplatform. Het zijn bouwstenen die zonder architectuur, scoring, en governance operating model richtingloos blijven. Precies daarom bestaat DjimIT: om van deze catalogus een governed catalog te maken.

---

DjimIT helpt organisaties met sovereign AI-infrastructuur, governance-frameworks en enterprise AI-architectuur. Meer weten? Bekijk onze diensten of neem contact op.