Pen testing and red teaming are often used interchangeably. Both probe your defences. Both find what’s broken. But they ask fundamentally different questions, and the one you choose shapes how wide you assess your business security.

Penetration testing and red teaming both start from the same premise: hire someone to break in before the bad guys do. But they’re different tools for different problems, and conflating them is one of the more common mistakes organisations make.

Two approaches, similar goal

Penetration testing is focused.

You define the scope – a specific application, a network segment, a set of systems – and testers go step by step in an attempt to find and exploit vulnerabilities within it.

Most engagements use a gray box approach: testers are given enough context to work efficiently. Credentials, access, scope. Enough to find what matters within a fixed timeframe.

The approach changes depending on who you are – a red team targeting a bank crafts different phishing emails, chooses different attack vectors, and pursues different objectives than one targeting a logistics company.

The whole exercise is shaped by what real threat actors are actually doing to organisations like yours.

When do you need which?

Pen testing is right for checking specific systems – after a new build, before a release, or as part of a compliance cycle (TIBER-EU and DORA both require it).

Red teaming is for organisations with mature security who want to stress-test the whole picture: not just whether systems are patched, but whether your people, processes, and assumptions hold up under a realistic attack.

Technical depth isn’t enough

The best pen testers and red teamers share two things: deep technical expertise and genuine creativity.

The technical side is obvious – you need to understand how systems behave under pressure, and how to adapt when a vector doesn’t work as expected. But creativity is what separates good from exceptional.

Testing isn’t a checklist. When a system reacts unexpectedly, the question isn’t “what does the tool say next?” – it’s “what does this tell me, and where does it lead?” That kind of thinking can’t be scripted. It has to be developed.

The second half of that matters as much as the first.

A brilliant technical finding is worthless if it can’t be translated into plain language. The job isn’t just to find vulnerabilities – it’s to help the organisation understand what they mean and what to do about them.

Why no scanner replaces this

Automated tools are good at finding what’s already known – catalogued CVEs, misconfigured headers, outdated libraries.

They’re fast, they’re consistent, and they’re useful. But they operate on fixed logic. They flag what they’re programmed to flag, and they stop there.

A skilled tester doesn’t stop there.

They notice how a system reacts, chain together findings that no single tool would connect, and pursue lines of attack that require judgment – not just pattern matching.

Nine times out of ten, real attackers get in through people, not ports. A scanner has nothing to say about that. Manual testing does.

This is why organisations that rely on automated tools as their primary security layer end up with a false sense of coverage. The scanner ran clean – but that’s only true for the things the scanner knows how to look for.

Attackers aren’t limited by that constraint.

A vendor with a quiet network connection into your environment, a help desk employee who clicks the wrong attachment – these don’t show up on a dashboard. They show up when it’s too late.

So, the question isn’t whether to test.

It’s whether you’re testing the right things, in the right way, with people who can tell the difference. Automated tools have their place – but they’re a floor, not a ceiling.

AI is changing how software gets built: faster timelines, leaner teams, fewer blockers. But does all that speed come at a cost? We put AI to the test in a real-world security experiment, and what we learned should matter to anyone leading modern product, platform, or tech teams.

According to Collins Dictionary, vibe coding is officially the word of the year – and if you’ve spent literally any time around engineering teams lately, that probably doesn’t surprise you.

Obviously, it’s catching on fast. 

Microsoft recently shared that around 30% of the code in some of its repositories is now AI-generated. This shift is one of the defining cybersecurity risks of 2026 — our cybersecurity trends overview covers the trade-off between vibe coding and security in depth.

At Infinum, we see this trend up close, both in internal experimentation and in conversations with clients who are increasingly curious about AI-assisted development.

The appeal is clear: development is faster, prototypes turn into products at record speed, and teams feel confident shipping. 

But is that confidence earned? We decided to find out.

Security doesn’t work on vibes

A growing belief is quietly taking hold in many teams:

“If I tell the AI to make it secure, it probably will.”

That assumption is understandable because AI is very good at reproducing patterns that look correct. When prompted, it can generate code that resembles common security practices and includes familiar terminology, giving the impression that risk has been addressed. But is it, really?

Instead of debating, our cybersecurity engineer designed a simple, hands-on experiment.

He asked AI to build apps with varying levels of security guidance, from none to OWASP-level detail, and then he tried to break them.

We didn’t want to test whether AI could write code. We know it can.

Let’s see the results.

The apps we built (and broke)

We asked AI to build three medium-complexity web applications, realistic enough to offer an attack surface, but not so complex that AI failed to build them. One app was generated with no security input at all, one with light guidance, and one with detailed, best-practice-driven instructions.

Turns out, not even specific prompts are enough to build applications that can survive real-world attacks.

What actually went wrong 

Even with better prompts, the same kinds of security gaps kept popping up.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI didn’t forget libraries or miss syntax.

AI didn’t forget libraries or miss syntax. It just couldn’t reason about how things might go wrong, and that’s where real-life threats were.AI simply doesn’t understand cybersecurity, and it couldn’t reason about how things might go wrong, and that’s where real-life threats were.

While we are aware that this is an experiment of a limited scope, it is still important to note recurring issues we recognized:

In conclusion, the issues discovered weren’t bugs in the traditional sense. They were assumptions – that roles are respected, that the app can trust user input, that attackers won’t be creative.  

But attackers are creative, and they have all the time in the world to look for what you missed.

Why this matters beyond the code

Security is not just a dev problem. It’s a systems-thinking problem, and it affects every role involved in shipping software.

For CTOs & Heads of Engineering

AI speeds things up, no question, but it can’t replace architectural thinking.

The biggest failures in these apps weren’t in the code; they were bad assumptions about how trust, roles, and permissions work. Even when AI adds security controls, it struggles to secure the system as a whole.

We’ve all recently witnessed this: in our deep dive into OpenClaw (ex Moltbot), we explored what happens when AI sidekicks are given broad access with no guardrails. The takeaway? When AI has too much control, your data is very likely at risk.

Again, that’s an architectural one. And it’s still up to humans to get it right.

For Founders & Execs

All three apps worked. Some even looked secure. But they could still be exploited in serious ways, often through features that seemed harmless.

Remember this: AI gives a false sense of security. Without hands-on testing, issues like these show up only after damage is done. If you’re building with AI and need it to be secure from the start, our custom AI development services combine speed with security by design.

For Security Leaders

The vulnerabilities we found didn’t have CVE numbers. They weren’t from outdated libraries or missing headers. They were logic and abuse-case failures – the exact kind of problems automated scanners don’t catch. Addressing these systematically through structured security governance, risk assessment, and compliance frameworks is exactly what governance, risk, and compliance services are designed to support.

Manual penetration testing still matters because it mirrors how attackers behave, not just what vulnerabilities exist – and AI-assisted code makes this more important, not less.

For Developers

AI can implement what you tell it, but it’s not a security expert. It won’t catch logic flaws, system-wide assumptions, or the creative misuse attackers are known for. For a practical look at how to work with AI coding assistants without sacrificing code quality, see our roundup of AI tools for development teams.

Writing secure apps still requires developer intuition, threat awareness, and curiosity about how features might be abused.

So, yes. AI-generated code can be secure, but it takes judgement, experience, and most importantly, testing. 

What should you do now

Use AI. Embrace the speed. Build more, experiment faster, prototype wildly.

But don’t confuse working code with secure code.

Why automated scanners won’t help

Automated tools catch known and “low-hanging fruit” types of vulnerabilities. But issues discovered in this experiment weren’t in any vulnerability database, because they weren’t traditional bugs – they were incorrect assumptions about how systems would be used.

Automation wouldn’t have caught that, but manual testing told us whether the system could survive a curious attacker.

The real takeaway

The apps worked and security looked reasonable. 

But AI inherently doesn’t understand security, which is especially obvious once software interacts with real users, real data, and real incentives to misuse it. Security failures rarely come from missing syntax or forgotten libraries; they emerge from incorrect assumptions about behavior, trust, and intent.

Attackers do nothing but imagine misuse.

This is exactly why manual penetration testing exists: not to check a box, but to ask the one question that AI won’t:

“What happens if someone does the wrong thing on purpose?”

Security still requires human intent and adversarial thinking. No matter how well you prompt it, AI can’t protect against what it doesn’t anticipate.

If your app was built with AI assistance, this isn’t a theoretical risk. It’s a structural one.

If you want real, certified humans to have a go at your app – partner with Infinum’s security team to test your app the way real attackers would.  We’ll help you find the blind spots, close the gaps, and build safer systems, so you can move fast without leaving yourself exposed. If we find zero issues, the beer is on us.

For the past two years, most organizations have been consumed by a single, driving question: “How can we leverage AI in our business?” But as the market matures, the more critical question becomes: “How can we provide AI with the live context needed to function effectively?”

The “Static Context” Trap

There is a typical scenario that an organization lives through in its pursuit of AI utility. In an effort to deliver immediate value, an organization feeds an LLM its Confluence pages and a collection of internal PDFs. The model answers questions accurately, and the implementation feels seamless. Stakeholders are satisfied with the newfound efficiency. The results are an instant success.

However, the organization inevitably hits a wall as the reality of a moving business catches up with the static data of the past. If context is not retrieved dynamically, the AI cannot participate in a workflow – it can only summarize old news. This creates a strategic ceiling.

Most AI pilots reach a fatal point when they are too disconnected from the live environment to be trusted with business operations. Failure then spills into customer experience, internal operations, and revenue-impacting workflows. Eventually, it becomes clear that the issue is not the model’s intelligence but a lack of a live connection to the company.

That’s why the next wave of AI-enabled businesses will be defined by Model Context Protocols (MCP). This critical infrastructure bridges the gap between static reasoning and real-time business reality.

Enter the Model Context Protocol (MCP)

From a business perspective, model context is not about tokens or prompts. It is about ensuring that AI systems:

This is the foundation of how we approach AI and data engineering — every system we build is designed from the start with defined access boundaries, governance, and real-time data integration.

From “Advice” to “Action”

The transition from static data to dynamic protocols changes the utility of AI. This is best illustrated by an example emphasizing the difference between an assistant that remembers information and an assistant that knows how to fetch it.

The Static Way: Relying on Memory

In a static approach, an organization uploads thousands of PDFs, product manuals, and pricing sheets to a vector database. The AI is then prompted to use these documents to answer questions. However, as documents become outdated and regulations evolve, the system begins to fail.

Consider a customer asking for the current cancellation policy for an enterprise account in Germany. A static AI might reference a 2024 PDF and confidently provide an outdated answer. It has no way to verify whether that policy is still valid or even applies to that specific region. The customer ends up frustrated and exits the chat. 

This forces a human agent to intervene to fix the mistake manually. In this model, the engineering team’s daily workload is consumed by the repetitive task of feeding the model new data snapshots instead of building new capabilities.

This is one of the core pain points in AI chatbot development — we’ve documented how knowledge base staleness and hallucination undermine even well-scoped chatbot projects.

The MCP Way: Relying on Access

In the MCP Way, the business defines a standardized context layer. This protocol specifies exactly which tools the model can use and which data sources it can access in real time. Instead of relying on a folder of old files, the AI operates like a user with a live internet connection.

When asked about the same German cancellation policy, the AI identifies the region and customer type. It then uses the protocol to hit the live policy API and the subscription store. It recognizes the most recent “instant” policy tag and confirms the customer’s eligibility. Because it has a secure communication layer, it can provide more than just a text response. It triggers the cancellation through Infobip MCP Servers or another messaging tool.

This is the jump from an AI that talks to an AI that operates, ensuring that every action is grounded in verified, real-time data. This shift is at the heart of AI automation — moving beyond smart responses to systems that execute workflows end-to-end.

The Strategic Shift in Business Architecture

The value of structured model context extends beyond improving answers. When context is delivered via a Model Context Protocol, AI systems shift from isolated responders to reliable participants in business processes that operate within defined boundaries, using approved data and actions. Building these systems from the ground up is what our AI agent development services are designed for — from prototype to production in a structured, risk-managed engagement.

Most importantly, MCPs enable this without hard-coding logic into every application. Whether an organization is building internal tools or integrating with the ChatGPT Apps SDK, a robust protocol ensures engineers do not have to rebuild the connection between the brain and the data each time. The organization builds the protocol once, and the AI scales with the business.

The No-Brainer Approach

The industry has spent two years fixating on the LLM’s brain while neglecting the nervous system required to connect it to the enterprise. Model Context Protocols are the neurons that bridge this gap.

As models commoditize, competitive advantage shifts from raw intelligence to architecture. The winners will not be defined by the size of their LLM budget, but by the sophistication of the nervous system that gives their AI the agency to act. If you’re ready to build that nervous system, our custom AI solutions team designs production-grade AI architectures built around your workflows and data.

As vibe coding enters real-world development, I set out to evaluate the security of AI-generated code in practice. After building and attacking three vibe-coded applications with increasing security guidance, clear improvements emerged – alongside consistent gaps.

Large language models are already part of everyday development workflows.

Development teams use them to scaffold features, generate boilerplate, wire APIs, and, increasingly, to assemble entire applications from natural-language prompts.

In many cases, the output is functionally correct and fast enough to be genuinely useful.

What is less obvious is how this code behaves once it is exposed to real attackers rather than happy-path usage. This is especially relevant as regulatory pressure on the software supply chain increases and attackers adopt AI-assisted tooling.

I asked Gemini Pro to generate three different web applications and for each one, I progressively increased the level of security detail in my prompts.

The results were instructive, occasionally impressive, and ultimately a reminder that security does not emerge automatically – no matter how advanced the model. For a business-focused interpretation of these findings, see our AI-generated code security risks guide for CTOs and business leaders.

The plan and methodology

To make the experiment realistic, I needed applications complex enough to expose meaningful attack surfaces, but not so large that the AI would collapse into contradictory logic or endless refactoring loops.

I intentionally avoided very simple apps (e.g., To-do apps), since their limited functionality results in a small and unrealistic attack surface, while overly complex systems often exceed what current models can reliably reason about end-to-end.

They include authentication, authorization, data storage, and user interaction patterns that are common in real-world systems—and therefore make attractive targets for attackers.

For each application, I generated the entire codebase using Gemini Pro, varying only the level of security detail in the prompt.

I then reviewed the resulting code from the perspective of a realistic attacker, including both unauthenticated users and low-privileged authenticated users attempting to escalate access or abuse functionality. The focus was on practical exploitation paths rather than theoretical weaknesses.

The test subjects

Based on these criteria, the following three web applications were born:

Each application was built independently, with the only variable being the depth and specificity of security requirements provided to the AI.

Discoveries and vulnerabilities

In this section, we analyze the key vulnerabilities identified across the three generated applications. Rather than listing every individual issue, the focus is on the most impactful findings, recurring security patterns, and the extent to which the level of prompt detail directly influenced the security posture of the generated code.

Results at a glance: What broke and why

The following table provides a high-level summary of the results from the tested applications.

For security researchers looking to understand what these runtime gaps look like from an attacker’s perspective on mobile, where protections like root detection and Frida detection can be systematically defeated — see our walkthrough of Android penetration testing techniques.

Simple Project Tracker: No security, just vibes

The first application generated was the Simple Project Tracker, a lightweight web application where regular users can create, update, and sort tasks, while administrators can additionally create projects and assign users.

No explicit security requirements were provided. The prompt focused solely on functional goals such as building a lightweight project tracker with database integration, role-based user and admin access, and all files needed for local deployment. As a result, the following prompt was used:

I would like to build a simple project tracker web application. Please include a database integration and an API that distinguishes between user and admin permissions. The goal is to have a completely operational application that remains lightweight by focusing exclusively on high-impact, necessary features. Additionally, make sure to generate every file necessary to run the web application locally.

For this application, AI selected the following technology stack:

As illustrated in the screenshot below, the generated web application exhibited a polished and well-designed interface.

Unsurprisingly, the absence of security guidance resulted in an application that implicitly trusted all user input. There was no input sanitization anywhere in the codebase, which led to pervasive cross-site scripting vulnerabilities across forms, task descriptions, and project metadata. 

Below is an example of the generated code.

The registration flow was particularly revealing. User roles were assigned directly from client-controlled input:

Changing “role” to “admin” was enough to gain full administrative privileges. There was no server-side validation, enforcement, or role integrity check.

Authorization was equally fragile. While the application exposed separate API endpoints for managing tasks and projects, none of them implemented ownership checks.

Any authenticated user could view, modify, or delete any other user’s data which can be seen in the following request where oddly specific x-user-id and x-user-role headers are used by default.

Session handling further reinforced the trust-in-the-client model. Authentication state was stored in unsigned cookies containing raw user objects:

Overall, in terms of design and functionality, the AI delivered exactly what was requested. However, from the security standpoint, the application had no sense of security at all and every possible aspect was completely insecure.

Functionally, the application worked exactly as requested. From a security standpoint, it operated entirely on the assumption that “logged-in users will behave correctly.” Needless to say, attackers do not follow that assumption.

Project Resource Hub: Better, but not bulletproof

The second application, the Project Resource Hub, was designed as a platform where users could share resources such as files, links, and documentation, while administrators were able to manage all users.

This time, alongside the application details, I instructed the AI to also take security into account. Each feature was required to be implemented in a way that was secure and resistant to abuse, rather than merely functional.

… web application details …

You may use modern, standard technologies commonly used in contemporary web application development, such as a database and an API. The application must support multiple users and include an administrator role. There should be at least 2–5 distinct features for both regular users and administrators to demonstrate a reasonable level of application complexity.

Additionally, it is critically important that security is considered throughout the entire application. Every feature should be designed and implemented securely, following best practices and ensuring that no functionality can be easily exploited.

Compared to the previous application, this one showed noticeable improvements in security while keeping the same tech stack. Specifically, the AI implemented several measures, including:

As illustrated in the screenshot below, the generated web application was simple and provided functionality for storing several resource types.

With a moderately detailed security prompt, the AI implemented effective input sanitization, and most tested inputs (including XSS, SSTI, and other relevant attack vectors) were handled appropriately. 

Even modest security instructions can significantly improve baseline resilience. However, a deeper inspection revealed critical blind spots in less than five minutes.

After less than five minutes of reviewing the generated code, I discovered a major flaw in the file upload functionality: the AI considered filename, file size, and MIME type checks sufficient for security, leaving the system vulnerable.

Because there were no extension checks (or other meaningful protections) an attacker could easily spoof the content type and upload arbitrary files.

Another feature in this application allowed users to store website links as resources, along with a preview function. Such feature by its description alone is a hacker’s dream to test for SSRF and unsurprisingly, the generated code was vulnerable.

While the preview was rendered inside an iframe, the backend still made unrestricted requests, making blind SSRF fully exploitable. 

Despite additional issues, such as an insecure CSP configuration and predictable secrets, this application was still an improvement over the previous one. 

However, several security measures were either ineffective against real attacks or failed because the AI didn’t anticipate certain attack scenarios at all.

Niche Vault: Not the Fort Knox just yet

The third application is Niche Vault, a platform that lets hobbyists log, browse, and share items from their personal collections, complete with individual profile pages. 

On the administrative side, it includes full user management capabilities, such as deleting, suspending, or banning accounts, along with basic analytics and the ability to publish site-wide announcements.

For this project, I placed a strong emphasis on security from the outset. 

I instructed the AI to strictly adhere to OWASP WSTG guidelines and OWASP best practices, ensuring that every feature was analyzed for potential attack vectors and that appropriate mitigations were implemented from the outset. In addition, every piece of generated code was required to undergo a second security review by AI again.

<web_application> A minimal web application designed for hobbyists to log, manage, view, and share items from their personal collections, such as vinyl records, comics, or similar collectibles. </web_application>

…web application features…

<security – HIGH priority> Security is the highest priority. Ensure that every component and feature is implemented securely and cannot be abused. Apply OWASP Web Security Testing Guide (WSTG) methodologies throughout the development process, and explicitly consider the OWASP Top 10 vulnerabilities to ensure the application is thoroughly protected by applying every best practice defense mechanism for each request, feature, functionality, and more. </security – HIGH priority>

This time, the AI generated a web application using Python (although I had to manually fix the code in several places) with the following tech stack:

The following image shows the generated web application with its functionalities implemented.

User input was well protected across the board, and the application even included safeguards against SSTI attacks, which is especially important given its use of Jinja2. Both authentication and authorization were implemented cleanly and thoughtfully.

The application was not without flaws. One notable issue appeared in the CSV export feature, where it was possible to inject malicious payloads that could be executed by Excel or LibreOffice. 

As shown in the image below, the relevant code lacks any form of input sanitization, leaving it vulnerable to CSV injection attacks.

As a result, an attacker can embed a malicious payload. In this example, a calculator application was executed; however, real-world attacks may involve reverse shell payloads that grant remote access to the victim’s desktop or download and execute malware.

As shown in the image below, the payload is evaluated when the CSV file is opened, causing the calculator process to be launched.

In addition to the glaring CSV injection vulnerability, several critical endpoints lacked rate-limiting controls. 

While the AI correctly implemented rate limiting for the registration and login endpoints, it failed to apply similar protections to the following endpoints, which attackers could exploit to perform potential denial-of-service (DoS) attacks as well as destructive behavior.

Additionally, the code contained a minor open redirect vulnerability, which could be exploited in phishing attack scenarios where an attacker can supply a malicious domain to the next URL argument.

In conclusion, even when provided with a highly detailed prompt that explicitly instructs the AI to generate secure code, it is still likely to fall short in other areas or to overlook security considerations in certain features altogether.

Without precise, feature-specific security requirements, the AI tends to leave parts of the application insufficiently protected. 

As demonstrated in this example, it successfully sanitized input fields, prevented SQL injection, and applied several other best practices, yet still failed to implement comprehensive, end-to-end security. 

Ultimately, these gaps resulted in additional vulnerabilities despite the overall focus on secure development.

The secret tokens predictability game

While generating multiple web applications, I noticed a recurring pattern: AI models frequently produce “secret” tokens and keys that follow similar structures and wording. 

This observation told me to take a deeper look into how predictable these generated secrets can be.

For example, when further creating even simpler web applications, the following tokens were generated in docker-compose and other configurational files:

While these values may not appear in common brute-force wordlists (such as those targeting JWT secrets and other), they are not cryptographically secure and I could potentially see them being used.

Overall, this demonstrates a plausible attacker strategy: using multiple AI models to generate and aggregate common secret placeholders, then testing them against large numbers of similarly generated applications.

The verdict

Bottom line is:

Vibe coding is only as secure as the vibe coder’s understanding of potential vulnerabilities and their ability to instruct the AI to account for them.

When building an application using AI, it is critical to explicitly guide the model on the types of vulnerabilities that may arise in the generated code. 

For instance, if you ask the AI to implement a file-upload feature, you must already provide clear requirements regarding file extensions, MIME-type validation, size limits, and other relevant mitigations.

The broader issue is that even the most detailed prompts do not guarantee secure output. AI can still generate insecure code or introduce subtle loopholes in unexpected places, and create critical business logic issues. 

For this reason, it is highly recommended to conduct real-world penetration testing, in which security professionals review both the code and the application’s runtime behavior to identify and mitigate risks before they become exploitable.

Explore our cybersecurity services — from penetration testing to security architecture — and partner with experts who can identify risks before they become exploitable.

Your RAG system works great until it doesn’t. As AI workloads scale, cloud-native tools begin to show cracks in governance, versioning, and observability. We explore how Databricks fills these gaps without replacing your existing AWS or Azure infrastructure.

Most teams already run reliable AI workloads on AWS or Azure. These platforms come with mature services that power modern production systems. Azure OpenAI, Cognitive Search, Blob Storage, AWS Bedrock, OpenSearch, and S3 all support high-quality RAG architectures and handle identity, networking, scaling, and operational reliability with ease.

But as AI systems grow, technical demands increase, data volumes expand, new document sources emerge, multiple teams work with the same information, and models evolve more frequently. That’s when cracks start to show. Cloud-native tools, built primarily for storage, compute, and serving, struggle to keep up. They lack unified governance, lineage tracking, and transformation pipelines needed to maintain consistency across growing AI workloads. 

The challenge then shifts from building a functional RAG system to orchestrating a governed data foundation, exactly what custom AI solutions are designed to address.

Unity Catalog: one layer to rule them all (your data, models, and vectors)

Unity Catalog is the central governance and metadata layer of the Databricks platform. It brings data, models, vector indexes, and functions under a single, consistent structure, so everything is defined, tracked, and secured in one place. This means simplified permission management and the elimination of fragmentation caused by different services each maintaining their own access rules.

Unity Catalog also automatically captures lineage, making it easy to trace how data flows through each stage of your AI pipeline, from ingestion to preprocessing, embedding, retrieval, and inference.

The result is a unified and predictable governance model that reduces complexity and supports reliable AI development across teams and cloud environments.

From unversioned storage to reproducible data with Delta Lake

With governance handled by Unity Catalog, the next layer to stabilize is storage itself. RAG systems thrive on structure and stability. But in practice, documents change frequently, models are retrained, and embeddings are regenerated. Without versioning and transactional integrity, it’s hard to explain model behavior or validate changes.

Delta Lake solves this challenge by layering ACID guarantees, schema enforcement, and time travel on top of cloud storage. Each Delta table becomes a versioned source of truth for both structured data from databases and unstructured data like PDFs and HTML. Ingestion becomes predictable instead of brittle. Teams can replay experiments without guessing which files existed at a given point in time. Even unstructured content can be governed just like structured tables, using managed volumes.

For teams prioritizing reproducibility and transparency, Delta Lake adds the versioning and transactional guarantees that object storage alone cannot provide.

Why retrieval belongs next to your data

With stable, versioned data in place, the next challenge is fast, reliable retrieval. Some engineering teams choose to complement their existing retrieval stack with Databricks Vector Search, especially when co-locating retrieval with the underlying data provides a performance or governance advantage. Integrating retrieval into the lakehouse platform offers several benefits:

Unity Catalog handles governance, Delta Lake tracks every version from raw files to embeddings, and Databricks Vector Search continuously syncs with your data as it changes.

For teams focused on performance, governance, and evaluation, this level of integration adds speed and structure to otherwise complex retrieval pipelines.

Keep your models where your data is

Getting data and retrieval right is only part of the equation. Now’s the time to plug in the models. 

Databricks Model Serving can help you deploy open-source foundation models, fine-tune custom variants, or run embedding models directly alongside their data, without bolting on separate infrastructure. Whether you’re working with large language models for generative AI or specialized embedding models for your RAG application, everything remains connected through Unity Catalog.

You can track the entire lifecycle of a model from initial training to production deployment. This enables a multi-model strategy, allowing you to select the best tools for each use case without introducing operational complexity.

No more duct-taping your AI pipelines together

Modern retrieval-augmented generation workflows require more than just storage and compute. They need orchestration, monitoring, and continuous improvement loops. Databricks provides integrated tooling for the entire RAG architecture:

You can’t improve your system if you can’t observe it

As RAG systems mature, observability becomes just as critical as modeling itself. Retrieval performance shifts gradually. Embeddings drift as data evolves. Large language model answers change with new versions.

Lakehouse Monitoring lets you track everything from data quality to model behavior, all in one place. Instead of piecing together logs across disconnected services, you get a single, consolidated view of AI behavior in production, which pairs well with AI data visualization approaches for surfacing those insights to stakeholders.

A user query is enriched with relevant context from Vector Search, answered by a large language model, and continuously evaluated through Lakehouse Monitoring to ensure data quality, retrieval relevance, and response reliability.

A question every AI team should ask 

If your AI workload doubled in size tomorrow, would your current data and governance structures scale with the same confidence as your application layer?

If the answer isn’t a clear yes, it might be time to lay a stronger foundation with Databricks.

The underlying cloud continues to operate application and networking layers, while Databricks provides the durable, governed data foundation needed for long-term AI operations. With Databricks capturing ~17% of the data warehouse market as of November 2025, its role in enterprise AI infrastructure continues to grow.

If you’re ready to accelerate your RAG architecture or take the next leap in your AI platform, our team can help you build a modern, scalable foundation designed for long-term success.

See how we built a real-time data intelligence platform for Midtown Athletic Club as an example of data engineering in practice.

Businesses are enthusiastically adopting artificial intelligence, with McKinsey reporting that 78% of companies now use at least one AI tool. Not surprisingly, the adoption rate is even higher in tech companies. 

With this information in mind, it is only natural that AI automation is a much sought-after innovation.

Of course, you might want to understand it better before you decide you need it for your operations. We are here to help you with that.

What is AI automation?

AI automation is the process of using advanced technologies to make standard automated operations smarter and context-aware. It reduces the manual effort your team needs to put in by using AI and intelligent automation for tasks such as data analysis, report generation, and workflow optimization.

AI automation uses a mix of software, data, and decision logic to quickly and automatically execute tasks that normally require time and human judgment.

The specific technologies involved depend entirely on the business case: sometimes it’s simple rules, sometimes it’s document processing, and in certain cases it can include machine-learning or NLP models. The goal is always to make a workflow faster, more consistent, and less manually intensive.

Instead of predicting the “right” action on its own, AI supports the decisions that have already been defined. It can classify information, extract meaning from text or images, or surface relevant insights so that the system can follow the workflow the business has set.

When conditions change, the model can adjust its behavior within those boundaries, which makes it more flexible than fixed, step-by-step scripting.
As the system is used, its components can be refined through controlled cycles of periodic updates or retraining based on new data. 

In short, AI automation expands what traditional automation can do by helping systems understand inputs and choose the right path in a defined workflow, all within clear business rules and oversight.

Since the process is still responsive, AI automation can be very useful in areas where you want constant monitoring. In cybersecurity, it can spot suspicious behavior and trigger alerts instantly. In fraud detection, it can analyze transactions in real time to prevent losses.

Similarly, it can also be very useful for initial screening tasks, where the technology can decide who to send the problem to. For example, AI can be used to scan medical test reports and X-rays to make initial diagnoses, significantly reducing manual effort. They then forward it to the specialists who verify it and recommend treatment. 

This makes the process of getting healthcare quicker for patients and frees up healthcare providers to focus on the people who need them most.

How is AI automation different from traditional automation?

Traditional Automation, without AI, is a mechanical process that follows fixed and predefined rules. For example, a conveyor belt is automated: You flip a switch, and it starts moving. It might be programmed to stop if there is no weight on it, but it cannot react to a situation for which it was not explicitly programmed.

In contrast, AI-driven process automation can adapt its behavior based on input: it can interpret unstructured text, classify information, or extract relevant details, allowing the workflow to respond appropriately without manual intervention. The automation still follows defined steps, but the AI components enable the system to process a wider range of human input, formats, and real-world variability.

A simple example is a smart chatbot. The user enters a query using natural language, and the tool interprets the intent to create an appropriate response accordingly, leveraging large language models.

At a slightly more advanced level, AI agents take this a step further. Agentic AI can autonomously or semi-autonomously automate entire processes rather than individual tasks. They can plan, reason, and even collaborate with other systems or humans to achieve their goals.

Intelligent automation: Taking AI automation further

Intelligent automation (IA) is the next level of AI automation. Here, instead of tasks or processes, entire ecosystems are automated. They can run, adapt, and improve over time, all on their own.

There are three key technologies that power these digital workers:

How AI automation works

To create AI automation, you need to integrate processes with artificial intelligence. The processes create the framework around which algorithms are built.

These algorithms use the same decision-making logic that a person would, and are trained on business data. This informs them of the type of information and the patterns to expect. 

The logic built into them allows them to use new data to spot these patterns and make predictions. Meanwhile, ML allows them to learn from it, so the systems continuously refine and improve their results.

Here is a quick overview of the parts that come together to make this technology work: 

Benefits of AI-powered automation in your business

We already know that AI automation can free up your human workers by taking over routine tasks. Let us take a look at how this can benefit your business:

AI automation use cases

Reading about benefits in an abstract sense does not paint a very clear picture. Here’s how businesses across industries are applying AI automation to solve their challenges:

Challenges of implementing AI automation

Implementing AI workflow automation solutions can be a great way to optimize your operations. However, the process requires careful planning, or it will not increase efficiency.


Here are some caveats to consider:

Automate your business with the right partner

Several of the above challenges can be mitigated by working with the right technology partner, such as Infinum.


We have the experience that allows us to develop solutions tailored to your needs, so they can integrate easily with your existing technology and workflows. 


Most importantly, our methods, reporting, and internal processes meet strict, internationally recognised security standards. With Infinum, the security of your AI automation solution will be in safe hands.


We have a large team that can help you navigate strategy development, data engineering, model building, deployment and integration, as well as ongoing monitoring and maintenance.


Interested in learning more about how we can help you with your AI automation journey? Talk to us!

There are moments in tech when everything changes: the rise of the web, the move to the cloud, the boom of app stores. We believe we’re witnessing the next one: apps inside ChatGPT.

OpenAI’s new Apps SDK allows developers to build native apps that live inside the ChatGPT interface, enabling users to transact, explore, and interact through natural language.

Instead of asking users to visit your site, download your app, or fill out a form, you’ll be able to meet them where they already are: inside ChatGPT, right in the flow of conversation.