Working as a security engineer in IT often makes me realize something: the fundamental engineering skills of the people handling technology simply cannot keep up with the sheer speed at which new tools emerge. As I clean up after systems built on a “ship first, think later” mindset, I constantly run into people who champion the “relative importance of time and speed.” They argue that in business, timing is everything—treating security, governance, and verification as negotiable, secondary priorities. In contrast, when I insist on absolute values like strict data governance and system stability, I sometimes catch myself wondering: Am I just being an outdated, stubborn gatekeeper?

A Series on Interesting Phenomena Emerging in the AI ​​Era

Stage 1. Early Adoption (Ignorance, Blind Faith & Misuse)

  • Ep. 1 | Leaks & Costs: AI Turned into a PII Classifier — Reckless data ingestion and the reality of runaway token bills
  • Ep. 2 | Distrust: When “AI Says So” Trumps Decades of Senior Expertise — Hallucinated answers replacing seasoned engineering judgment

Stage 2. Diffusion (Role Collapse & Contribution Conflicts)

  • Ep. 3 | Delusion: The Manager’s Vibe-Coding Fantasy — Underestimating engineering complexity by thinking anyone can build production software
  • Ep. 4 | Chaos: Why Coding Requirements Infiltrated DBA Job Postings — The role-inflation trap driven by the “everyone must code” hype
  • Ep. 5 | Dismissal: “AI Wrote It, So What Did You Actually Do?” — Distorted performance reviews that erase architecture and debugging efforts

Stage 3. Endgame (Debt Explosion & Loss of Control)

  • Ep. 6 | Technical Debt: Product Managers Writing Code and the Compounding Interest — Prototype-level spaghetti code boomeranging into unmaintainable systems (coming soon)
  • Ep. 7 | Complacency: “Vulnerabilities? We’ll Just Have AI Swap the Library” — Ignoring dependency graphs and architectural blast radiuses until a security breach hits (coming soon)
  • Ep. 8 | Betrayal: This Isn’t the Deterministic System You Thought It Was — Non-deterministic behavior, context drift, and total systemic collapse (coming soon)

The real problem I keep running into is engineers who have plenty of bias for action but not much technical depth, picking up the “security engineer” title and using “relative importance” as cover for cutting corners. LLMs entering enterprise environments at scale has made this worse, not better. The pitch sounds reasonable: humans can’t sift through mountains of unstructured data for sensitive information, so let the LLM do it. Then you actually look at the system design and governance, and it’s often a mess.

There is zero calculation regarding which models are being used, whose infrastructure receives the prompts and payloads, or how the token consumption structure actually scales. Sensitive identification numbers, bank account details, and confidential internal business plans are dispatched to external API endpoints in real time. Running a single pipeline execution costs thousands of dollars. Looking at this setup, it becomes obvious that this isn’t genuine tech adoption—it is pure resource waste and a regulatory compliance time bomb.

Let’s examine the data leak risks and token cost explosions that occur during early enterprise AI adoption, breaking down how executives, buzzword-driven engineers, and real security engineers view the problem through the lens of “relative importance.”

relative importance

Early Enterprise AI Adoption Pitfalls: Ignorance Meets Misuse

The early stage of any technology adoption curve is almost always characterized by blind faith and uncritical hype. Driven by pressure to demonstrate business competitiveness, organizations routinely push governance frameworks and security controls to the back burner under the guise of “relative priority.”

The Reality of Uncontrolled Data Pipelines

The anti-pattern I see most often is routing raw, unstructured data straight into public commercial LLM APIs. Database dumps, support tickets, internal chat logs, sometimes tens of gigabytes of it, get pasted straight into prompts with instructions like “identify personal data or anomalies and suggest countermeasures.”

From an architectural standpoint, the flaws in this approach are severe:

  • Lack of Endpoint Trust: Sensitive data that must remain within the private corporate network is sent to the public endpoints of external SaaS LLM providers without proper encryption or traffic inspection.
  • Unverified Data Retention Policies: Teams rarely verify whether the API tier retains inputs for model retraining (fine-tuning/RLHF) or caches them on third-party servers for extended periods.
  • Irreversible Leaks: Once data leaves the internal perimeter and enters an external cloud, exercising data deletion rights becomes nearly impossible. The transfer logs alone can constitute immediate regulatory violations regarding unauthorized cross-border transfers or third-party data disclosure.

Cost Estimation Failure and the Lack of Token Economics

In LLM architectures, compute cost is measured in input and output tokens, not server runtimes. Engineers accustomed to traditional software licensing or standard server hosting fees often fail to grasp this economic reality.

Processing millions of unstructured log lines by feeding multi-thousand-token contexts repeatedly makes costs compound exponentially, even if individual API calls look cheap. Teams frequently build pipelines that cost thousands of dollars per batch run and blindly schedule them as recurring cron jobs. The automation originally adopted to cut costs ends up generating a cloud bill far higher than the manual labor it was meant to replace.

The Dangerous Synergy: Executive Impatience and Buzzword Engineering

The reason such flawed architectures clear review boards and make it into production comes down to internal organizational politics. It is driven by a toxic combination: leadership desperate for quick, visible results, and superficial engineers who exploit buzzwords to package reckless execution as “agility.”

+--------------------------------------------------------------------------+
|                                Executives                                |
|   - "Market entry speed and business delivery are the top priorities."   |
|   - "Skip the complex architecture details; just show me a working demo."|
+--------------------------------------------------------------------------+
                                     ▲
                     Distorted Alignment on "Speed"
                                     ▼
+--------------------------------------------------------------------------+
|                           Buzzword Engineers                             |
|   - "Speed is key: built the whole feature in days using external APIs!" |
|   - Conceal or downplay data leak risks, token spikes, and runtime bugs. |
+--------------------------------------------------------------------------+
                                     │
                             Isolate & Marginalize
                                     ▼
+--------------------------------------------------------------------------+
|                         Real Technical Engineers                         |
|   - "Security and cost containment are non-negotiable fundamentals."     |
|   - Propose on-premise sLLMs & regex pre-filtering → Labeled as blockers.|
+--------------------------------------------------------------------------+

Executive Misjudgment Driven by Vanity Metrics

For leadership, the primary focus is often showing market analysts and board members that the company is actively executing an AI transformation. To them, technology frequently serves as a marketing trophy rather than an infrastructure foundation that demands stability.

  • Fixation on Visibility: Executives are reluctant to allocate budget and time to foundational work like data pipeline sanitization or governance frameworks. They assign higher “relative importance” to tangible, demo-ready web interfaces that return answers instantly.
  • Shifting Risk to the Future: A false sense of safety prevails: “We’re using an API from a top global tech giant, so what could go wrong? We’ll deal with security issues if they happen.” Engineering validation is skipped, and production launches are approved without reviewing Data Processing Agreements (DPAs).
  • Obsession with Short-Term Metrics: Seeing a cheap pilot invoice of just a few dollars, leadership jumps to the conclusion that the solution is cost-effective and immediately demands company-wide rollout without evaluating long-term Total Cost of Ownership (TCO).

Buzzword Engineers Packaging Superficial Knowledge

Buzzword engineers capitalize on executive impatience. They avoid the grueling mechanics of engineering—deep protocol details, network packet flow, OS kernel behavior, and database lock contention. Instead, they pick up trending jargon and prompt tricks, selling executives on the narrative that “in the AI era, speed carries far higher relative importance than perfection.”

  • Tool Blindness and Outsourced Responsibility: They call expensive commercial APIs for tasks that could easily be solved with basic regular expressions or deterministic tokenizers. Because they lack the skills to design robust local systems, they offload all computational and analytical responsibility to the model.
  • Intentional Downplaying of Risk: Even when they suspect data leaks or runaway token costs, they deliberately avoid mentioning them to management. Legitimate risks are dismissed as “minor issues with low relative importance for this phase.”
  • Resume-Driven Development: They have little interest in the operational disasters their systems may cause down the road. Their priority is securing a resume bullet point—“Architected enterprise-wide automated PII detection using state-of-the-art LLMs”—before jumping to their next job.

How Pragmatic Engineers Lose Their Footing

When this alignment between leadership and buzzword engineers solidifies, engineers who focus on baseline stability and data protection find their influence sharply curtailed:

  1. Branded as Progress Blockers: Engineers who flag pipeline vulnerabilities, warn about compliance fines, or prove impending token cost spikes mathematically are dismissed as “rigid traditionalists who don’t understand business agility.”
  2. Marginalization of Real Work: Deploying private infrastructure, fine-tuning smaller models, and building deterministic pre-processing engines requires time and disciplined engineering. Meanwhile, a buzzword engineer strings together a quick script calling an external API and presents a demo within three days. In a culture driven solely by speed, rigorous engineering work is treated as obsolete overhead.
  3. Inheriting the Cleanup: While buzzword engineers claim credit and secure promotions, the inevitable aftermath—hefty API invoices, regulatory audit inquiries, and data leak investigations—is dumped onto the real engineers who were sidelined in the first place.

I am writing this because I have watched this dynamic play out firsthand. Early on, I thought there was value in learning from these buzzword-heavy developers. After all, practical business does require balancing engineering rigor with delivery speed. But give it a year or two, and the outcome is consistent: when teams elevate individuals who lack foundational engineering principles, the organization’s technical foundation and system stability eventually collapse.

Thousands of Dollars per Run: Real-World Failures and Incoherence

To see how severe this architectural disconnect can be, consider a real project aimed at scanning roughly 50 million lines of unstructured enterprise logs to identify sensitive personal and corporate data.

The Breakdown of an Unengineered Architecture

The team relied solely on calling a top-tier commercial LLM through basic scripts. The resulting numbers were disastrous:

[Flawed Pipeline Design]
Raw Log Data (100GB) 
  → Script Chunking 
  → Sent to External Commercial LLM API (~4,000 tokens per prompt)
  → Response Stored in DB
  • Data Volume: ~50 million log lines (hundreds of millions of tokens)
  • Call Structure: Raw, unprocessed text fed directly into an expensive multilingual LLM
  • Cost per Full Scan: ~$2,500 to $3,500 per execution
  • Scheduled Frequency: Nightly batch job

Running an unoptimized pipeline that burns thousands of dollars every night is completely unsustainable. Over a month, a basic log-scanning job would run up a massive infrastructure bill—costing far more than hiring dedicated security analysts to conduct manual audits. Using the “relative importance of speed” to bypass proper architecture led directly to fiscal disaster.

Far worse than the compute bill was the compliance exposure. The logs processed through this pipeline contained:

  1. Account numbers and government identification numbers
  2. API secret keys and plaintext credentials
  3. Internal performance evaluations and confidential strategy roadmaps

All of this data was shipped unredacted to external public cloud endpoints. This constituted an immediate failure of baseline technical and administrative data protections, qualifying as an unauthorized external data transmission subject to major regulatory penalties.

While the team celebrated how accurately the AI flagged sensitive strings, the system was functionally operating as a high-throughput pipeline for leaking internal company data. Management cited NDAs and vendor agreements to justify the setup, but trusting legal paperwork alone to secure raw data flowing through third-party APIs reflects a fundamental misunderstanding of infrastructure security. For an engineer, physical network boundaries and packet-level isolation are far more reliable than words on paper.

A Sustainable Architecture for AI Security Pipelines

Meeting business requirements for unstructured data analysis while strictly containing costs and privacy risks requires a disciplined hybrid architecture—balancing execution speed with uncompromising security controls.

[Optimized Security Pipeline Architecture]

[ Raw Data ]
     │
     ▼
[ Layer 1: Rule-Based Pre-processing Engine ]
  - Regex-based masking for structured identifiers (IDs, card numbers)
  - Entropy analysis to filter hardcoded secret keys
     │ (Filters ~85% of volume; drastically cuts tokens)
     ▼
[ Layer 2: Isolated Private sLLM (On-Premises / VPC) ]
  - Lightweight open-source model (≤ 8B parameters)
  - Contextual sensitivity detection and automated obfuscation
     │
     ▼ (Only sanitized, approved text proceeds)
[ Layer 3: High-Tier Commercial LLM (Selective Calls Only) ]
  - Edge cases, complex compliance interpretations, and final reporting

Layer 1: Deterministic Pre-processing via Regex and Dictionaries

Never use an LLM for tasks that deterministic logic can handle. Government IDs, credit card numbers, email addresses, and standardized phone numbers can be detected with near-100% precision using regular expressions and basic pattern-matching algorithms.

  • Place a regex filtering engine at the very front of the pipeline to mask clear, structured personal data immediately.
  • Use Shannon entropy analysis to identify high-entropy strings, stripping out hardcoded API tokens and passwords.
  • This layer alone eliminates roughly 80% to 85% of the data volume from reaching downstream models, cutting token consumption by an equal margin.

Layer 2: Private, Lightweight Open-Source Models (sLLM)

Sensitive unstructured data that needs contextual understanding, things like conversational references to someone’s background, or internal codenames, should be processed inside an isolated environment, not shipped off to public APIs.

Modern open-source models in the 7B to 8B parameter range deliver solid performance on targeted domain tasks. These models can be hosted on internal GPU clusters or inside private cloud VPCs using high-performance serving frameworks like vLLM.

  • Network Isolation: Data never touches the public internet, satisfying core data residency and governance requirements.
  • Fixed Infrastructure Cost: Moving away from per-token billing to fixed compute capacity means analyzing hundreds of millions of log lines incurs no marginal cost spikes.
  • Domain Adaptation: Fine-tuning these models via parameter-efficient methods (like LoRA) on internal security guidelines delivers high accuracy on company-specific data patterns.

Building and tuning targeted models like this is where real engineering makes a difference. However, in companies where buzzword engineers have already dazzled executives with off-the-shelf API demos, securing support for this type of foundational architecture remains an uphill battle.

Layer 3: Context-Aware Anonymization and Controlled External Dispatch

Reserve external top-tier commercial LLMs strictly for complex edge cases that smaller models cannot reliably evaluate, such as multi-layered compliance interpretations or cross-language legal analysis.

Even then, raw text should never leave that boundary. Only data that’s already been sanitized, masked, and pseudonymized by Layers 1 and 2 belongs in the external payload. And you still need enterprise contracts with explicit zero-data-retention guarantees, so vendors can’t quietly use your inputs for model training.

Engineering Fundamentals: Control Over Blind Adoption

As AI tools become more capable, an engineer’s value is not defined by how quickly they can generate code or how creatively they write prompts. True competence lies in understanding the entire system lifecycle—controlling how each component impacts cost, security, and long-term maintainability.

The argument that speed takes absolute precedence over basic architecture is a convenient excuse used by those who cannot handle production-grade complexity. Superficial demos and hand-waving cannot survive long against real-world production traffic, astronomical API bills, and regulatory audits.

Organizations need engineers who can deliver business results without gambling with corporate data assets or burning infrastructure budgets. Tools will always remain just tools. The moment we stop thinking through system fundamentals and defer entirely to the software we use, technology ceases to be an asset and turns into an unmanageable liability.

By Mark

-_-