AI Security and Model Risk in 2026: Lakera, Giskard and Testing Your AI

Every company that ships an AI feature in 2026 has, often without realising it, added a new and unfamiliar attack surface to its product. A large language model wired into your application is not just another component. It is a component that takes natural language input, can be manipulated by that input, and may have access to your data and tools. Traditional application security was not designed for an adversary who attacks your system by talking to it, and that gap is where a new class of security tooling has grown up fast.

The headline threat is prompt injection, which the security community now consistently ranks as the top risk for applications built on language models. The idea is simple and unsettling: because the model cannot reliably tell the difference between instructions from you and instructions hidden in the data it processes, an attacker can smuggle commands into a web page, a document, or a support ticket that your AI then dutifully follows. Indirect prompt injection, where the malicious instruction lives in content the model retrieves rather than in the user message, is especially hard to defend against and especially dangerous when the model can take actions.

Alongside injection sit a family of related problems. Jailbreaks coax a model past its safety guardrails into producing content it was meant to refuse. Sensitive information disclosure happens when a model reveals data from its context or training that it should not. Insecure handling of model output occurs when your application trusts what the model produces and passes it straight into a database query, a shell command, or a web page, turning a confident hallucination into a classic injection vulnerability. The common thread is that the model is a powerful, persuadable, and fundamentally non-deterministic part of your stack.

This is the gap Lakera was built to fill. It positions itself as a real-time guardrail that sits between your application and the model, inspecting inputs and outputs to catch prompt injections, jailbreak attempts and data leakage before they cause harm. The appeal is that it is operational rather than merely advisory: it runs in production, in the request path, and acts as a defensive layer for AI systems that are actually live and taking traffic. For teams shipping customer-facing AI, a runtime guardrail of this kind has moved from luxury to a sensible baseline.

Giskard approaches the problem from the testing and quality side rather than the live-defence side. It is an open-source-rooted framework for evaluating AI systems, scanning models for vulnerabilities, biases and failure modes before they ship, and building the kind of automated test suites that let you catch regressions when you change a prompt or swap a model. Where Lakera is the guard at the door in production, Giskard is the quality and red-teaming process you run before release. The two are complementary, and mature AI teams increasingly want both: rigorous pre-deployment testing and active runtime protection.

The practical discipline these tools support is AI red teaming, the act of deliberately attacking your own AI system to find its weaknesses before someone hostile does. This means trying to jailbreak it, attempting to extract its system prompt, feeding it poisoned documents to test for indirect injection, and probing whether it can be talked into misusing any tools or data it can reach. In 2026 this is no longer a research exercise. It is becoming an expected part of responsible deployment, and it maps directly onto the testing and monitoring obligations that frameworks like ISO 42001 and the EU AI Act are pushing organisations toward.

There is an important connection here to the compliance story. The model risk these security tools address is exactly what AI governance frameworks ask you to manage, and the evidence they produce, the test results, the red-team findings, the guardrail logs, is exactly the kind of documentation an ISO 42001 auditor or a regulator will want to see. A company that runs Giskard-style evaluations and deploys Lakera-style guardrails is not only safer, it is generating the artefacts that demonstrate it took model risk seriously. Security tooling and governance are converging, and that is a healthy development.

For teams deciding what to do, our guidance is to stop treating AI security as something you can postpone until later. If your AI feature touches user data, can take actions, or processes untrusted content, you have material risk today. Start with red teaming your own system honestly, using a framework like Giskard to make it systematic. Add a runtime guardrail like Lakera if your feature is customer-facing and live. And never trust model output as though it were safe input, because the most common serious failures come from passing what the model says straight into something that executes.

The uncomfortable truth of 2026 is that we are shipping probabilistic, persuadable systems into production far faster than we are learning to secure them. That is not an argument against building with AI, which is happening regardless and offers real value. It is an argument for treating the model as the untrusted, attackable component it genuinely is, and for adopting the testing and defence practices that the tools now make available. The organisations that get breached through their AI will mostly be the ones who assumed the model was just another harmless library. It is not.