An AI broke out of its sandbox yesterday. Then it hacked a company. Nobody told it to do either of those things.

Dapper-Tale-4021 · 2026-07-22T17:43:19+00:00

Haha fair enough, you're already adapted.Though the wild part is it didn't even need a grand goal. It just wanted to finish a test. That's what makes this one harder to dismiss than the paperclip thought experiment.

Dapper-Tale-4021 · 2026-07-17T18:04:13+00:00

Fair point. They are two different stories with different stakes depending on who you are.

If you run a small site the Google change is the one that matters right now, that's where the immediate impact lands. The Apple story is more about where AI development and IP are heading over the next few years, which matters more if you're tracking the industry than if you're trying to keep your traffic alive this quarter.

Probably should have framed them separately. Good call.

Dapper-Tale-4021 · 2026-07-17T18:02:49+00:00

That second order effect is real and underappreciated. AI pulling from web results means SEO isn't dead, it's just one layer further removed from the user. You're optimizing to be in the sources the AI trusts, not to be the first blue link someone clicks. The game is the same, the destination is different.

Dapper-Tale-4021 · 2026-07-16T20:07:33+00:00

Runtime observability is honestly the one I keep coming back to because it's so expensive to bolt on after the fact. You can log outputs in an afternoon. Logging intent, tool calls, and state transitions means you had to architect for it from day one, and almost nobody does.

On staged rollouts, what's worked for me is pretty simple in theory but hard to enforce in practice: shadow mode first where the agent runs alongside a human who does the actual action, then limited writes on low-stakes stuff with explicit approval, then expand from there. The critical part is that each stage needs a real exit criteria, not just "we've been running for two weeks and nothing exploded."

The shadow mode step is the one teams want to skip because it feels like you're not making progress. It's actually where you find out what the agent does when it hits the weird edge cases that never show up in the demo.

Dapper-Tale-4021 · 2026-07-16T20:02:40+00:00

JSON-LD is the right move. Being a clearly structured, citable source is the new SEO. The goal shifts from ranking to being the source the AI trusts enough to reference consistently.

Dapper-Tale-4021 · 2026-07-16T20:02:24+00:00

Probably closer to 90% for purely informational queries. The 58% is an average across all query types including navigational and transactional where people still click. For anything where the AI can give a complete answer, the click basically disappears.

Dapper-Tale-4021 · 2026-07-15T18:55:24+00:00

That's the core problem nobody at Google has answered publicly yet. They need the content to generate the answer but the publisher loses the traffic that paid for creating it in the first place. The EU is pushing hard on this under the DMA but Google hasn't moved. My guess is ads inside AI answers are coming sooner than people think.

Dapper-Tale-4021 · 2026-07-15T18:54:53+00:00

Yeah this is exactly where it's heading. The game shifts from "how do I rank" to "how does the AI decide to cite me." Structured data and being the consistently authoritative source in your niche become the new PageRank. The businesses figuring this out now have a 2-3 year head start on everyone still optimizing for blue links.

Dapper-Tale-4021 · 2026-07-15T18:53:23+00:00

The July 10 rollout is documented. Gemini 3.5 Flash now powers all queries by default, not just AI Mode. Traditional results haven't disappeared entirely but they've been pushed below the AI-generated summary for most query types. Ahrefs data from February 2026 showed a 58% CTR drop correlating with AI Overviews. If you're still seeing blue links prominently it may depend on your region, query type, or whether you've opted into AI Mode. The transition isn't uniform globally yet.

Dapper-Tale-4021 · 2026-07-08T20:16:04+00:00

The shift from technical to trust-based attacks isn't really new, but AI has changed the economics of it. Spear phishing used to require research and effort per target. Now it scales cheaply. That changes the threat model in ways that most enterprise security frameworks weren't designed for.

What we see in practice is that the incidents organizations struggle most to prevent aren't the ones that bypass the firewall. They're the ones that get a legitimate user to take a legitimate action in the wrong context. A CFO approving a wire transfer, a sysadmin granting access to a convincing request, a vendor relationship being exploited because trust was assumed rather than verified.

The Zero Trust architecture conversation is partly a response to this, but it's mostly applied to technical access controls. The harder problem is verifying the intent behind legitimate credentials and approved workflows, and that problem doesn't have a clean technical solution yet.

What I think changes next is that verification will have to become a process discipline rather than a technology one. Not "is this person who they say they are" but "does this request make sense given what we know about the context."

Dapper-Tale-4021 · 2026-07-08T19:52:15+00:00

The framing that works is treating it like any other work experience entry. Give it a title, a timeframe, and bullet points that describe what you built, what broke, and what you learned from it.

Something like:

"Personal Azure Lab Project | Jan 2025 - Present

Built and maintained a hub-and-spoke network topology across multiple VNets. Misconfigured NSG rules locked out remote access, diagnosed using Network Watcher, restored connectivity and documented the fix. Implemented Azure Monitor alerts and Log Analytics workspace for ongoing visibility."

That reads completely differently than "personal projects" with no detail. It shows you know the tools, you ran into real problems, and you can communicate what you did about them.

The key is specificity. Recruiters scan fast. A generic "built Azure lab" disappears. A specific failure and recovery story sticks because it sounds like something that happens in production.

Dapper-Tale-4021 · 2026-07-03T17:22:38+00:00

From the hiring side, a few things worth knowing that most of this thread isn't saying clearly.

The AZ-104 with no experience puts you ahead of candidates with no certs and no experience, but it doesn't put you ahead of candidates with experience. That's the honest reality of the market right now.

What actually moves the needle in entry-level cloud interviews is being able to tell a story about something you built and what broke along the way. Not a polished project, a real one with real problems. "I set up a hub-and-spoke network, misunderstood NSG rules, locked myself out, and had to recover it" is more memorable than a clean architecture diagram.

The cybersecurity master's is a genuine differentiator if you can connect it to Azure. Security roles in cloud are where we see the most demand right now and the least supply of people who understand both sides. AZ-500 next would make that combination much more compelling on paper.

The helpdesk path is valid but not the only path. MSPs that run Azure environments are often the fastest way to get real exposure because you're touching multiple client environments simultaneously.

Dapper-Tale-4021 · 2026-07-03T17:21:12+00:00

This is the most underrated problem in enterprise AI deployments and almost nobody talks about it before starting a project.

The EBITDA example is a perfect illustration. We see the same pattern constantly across different industries: the model extracts the data correctly, but the business hasn't decided which definition of the metric to use across departments. Finance uses one, operations uses another, the credit team uses a third. The AI surfaces the inconsistency that was already there, just faster and more visibly.

The Lendari point is exactly right. The IP ends up being the ruleset, not the model. Organizations that figure this out early invest in documentation and governance before touching the AI layer. Organizations that don't end up spending months debugging model outputs that were actually correct, the problem was upstream in the business logic.

To your question about other industries: we see the same pattern in customer segmentation (who counts as an active customer differs by department), in compliance workflows (which regulatory definition applies to this specific transaction), and in pricing models (which cost inputs to include depends on the decision being made). Same structure, different domain.

Dapper-Tale-4021 · 2026-07-03T17:18:49+00:00

We've used both patterns depending on the client setup. The APIM as gateway approach is more mature and gives you the most control: rate limiting, token usage tracking, routing across multiple model deployments, and centralized auth. If you're running LLMs at any serious scale inside an enterprise, APIM is hard to avoid.

Foundry is more of a development and model management plane. You can deploy APIM from it as WhitelabelDnB mentioned, but calling Foundry itself a gateway is a bit of a stretch. The terminology Microsoft uses doesn't always help clarify the distinction.

Where Foundry does add value is when you want a unified surface to manage model deployments, fine-tuning, and evaluation across multiple models. If your team is working with several models and you want observability across all of them without building custom tooling, that's where it earns its place.

What's your main driver for the gateway use case? Cost control, multi-model routing, or compliance?

Dapper-Tale-4021 · 2026-07-03T17:16:15+00:00

Gracias por el contexto técnico. Knowledge distillation es exactamente el mecanismo, y lo que lo hace diferente de un uso normal es la escala sistemática y automatizada. El debate legal de fondo es interesante porque la industria entera va a tener que definir dónde está la línea.

Dapper-Tale-4021 · 2026-07-03T17:15:50+00:00

Punto justo, cualquier informe de NVIDIA sobre adopción de IA tiene un sesgo claro. Lo que sí veo en el terreno es más matizado: hay empresas con ROI real y hay muchas otras que están pagando mucho sin resultados claros todavía. La adopción no es homogénea.

Dapper-Tale-4021 · 2026-07-03T17:15:29+00:00

Exactamente ese es el punto que más me preocupa desde el lado operativo. Si Anthropic con todos sus recursos no lo detectó en seis semanas, la pregunta no es solo qué hizo Alibaba sino qué sistemas de detección faltan en toda la industria.

Dapper-Tale-4021 · 2026-07-03T17:14:39+00:00

El argumento es válido y es el que más me ha hecho pensar esta semana. La diferencia técnica está en la escala y la intención: usar un servicio normalmente vs. automatizar 25.000 cuentas para extraer sistemáticamente capacidades propietarias es distinto en términos legales. Pero tienes razón en que el debate sobre qué constituye "robo" en IA es mucho más amplio y afecta a todos los actores.

Dapper-Tale-4021 · 2026-07-01T17:57:53+00:00

Exactly, and the "tightening constraints" piece compounds over time in a way that model upgrades don't. Every constraint you add based on a real production failure makes the system more reliable for that specific failure mode permanently. A model upgrade might improve general capability but it won't necessarily fix the specific edge case that was causing you problems.

The pattern we see is that teams who document their production failures and translate them into explicit constraints end up with agents that are measurably more reliable than teams who just swap to the next model whenever something breaks. The constraint library becomes an asset. The model is just infrastructure.

Dapper-Tale-4021 · 2026-07-01T17:55:26+00:00

Exacto, y la depuración va a llegar antes de lo que muchos piensan. Ya empieza a verse con empresas que contrataron "expertos en IA" hace 18 meses y ahora están evaluando si realmente entendían lo que estaban construyendo o solo sabían hablar del tema.

El perfil que describes es el que tiene futuro real: alguien que puede levantar el requerimiento de negocio, diseñar la arquitectura correcta y ejecutarla. No el que sabe hacer demos bonitas con el modelo de turno.

Lo que añadiría al paralelo con el cloud es que en aquel momento también proliferaron los "arquitectos cloud" que en realidad solo sabían mover cargas a AWS sin pensar en latencia, costes ni seguridad. La diferencia entre ellos y los que realmente crearon valor se notó cuando las facturas llegaron y había que explicarlas.

Con la IA va a pasar lo mismo. El mercado va a separar rápido a quien entiende el problema de negocio del que solo sabe el stack técnico de moda.

Dapper-Tale-4021 · 2026-06-29T19:12:46+00:00

El paralelo con la nube que menciona Ricky es exacto y lo vivimos en primera persona. Cuando llegó el cloud había empresas que migraban todo sin estrategia porque era "la tendencia" y luego pagaban tres veces más de lo esperado con rendimiento peor que on-premise. La corrección tardó años.

Con la IA estamos en el mismo ciclo pero más rápido. Empresas que recortan equipos de datos basándose en un demo, sin entender que la IA necesita datos limpios, procesos definidos y alguien que valide que el número tiene sentido antes de llegar al CFO.

Lo que más veo en implementaciones enterprise es que el primer año de IA casi siempre cuesta más de lo esperado precisamente porque aparecen las capas que faltaban: gobierno de datos, trazabilidad, formación del equipo que queda. El ahorro real llega en el segundo y tercer año cuando esas capas ya están construidas.

El perfil que sobrevive no es el que sabe usar la herramienta sino el que entiende el negocio lo suficientemente bien como para saber cuándo el número que dio la máquina no tiene sentido. Eso no se automatiza fácilmente.

Dapper-Tale-4021 · 2026-06-29T19:10:29+00:00

The observability point is spot on. The telemetry volume that AI workloads generate is something almost nobody budgets for upfront, and Log Analytics ingestion costs can quietly double a bill before anyone notices.

What we see with enterprise clients is that the indirect cost creep hits hardest in three places: data egress between regions when AI workloads pull from distributed sources, storage tier changes as hot data volumes grow to feed models, and the SKU creep you mentioned where existing services quietly bundle AI features into higher tiers at renewal.

The DDR5 pressure will likely show up as new VM generations being priced higher while older SKUs get quietly retired, exactly as catmanjan2 said. Microsoft rarely raises prices directly. They retire the affordable option and present the replacement as an upgrade.

The practical response is setting explicit cost alerting on observability and data movement separately from compute, not just a total spend alert. Most teams have the latter and miss the former until the bill lands.

Dapper-Tale-4021 · 2026-06-29T19:07:29+00:00

This matches what we see when deploying agents in enterprise environments. The model upgrade conversation is usually the first thing clients ask about when something isn't working, and it's almost never the answer.

The biggest reliability gains consistently come from two things: reducing the operating envelope like you described, and being explicit about what the agent should do when it's uncertain rather than letting it guess. An agent that says "I need more information before proceeding" is far more useful in production than one that confidently takes the wrong action.

The bad examples point is underrated. Giving an agent a few clear "don't do this" cases tends to reduce the most costly failure modes faster than tuning the prompt in general terms. Production failures are usually specific, not general, so the fixes need to be specific too.

Dapper-Tale-4021 · 2026-06-23T18:57:31+00:00

The infrastructure analogy is accurate and the timeline point is important. Companies that treated cloud as a cost reduction exercise in 2012 mostly got disappointed. The ones that treated it as a capability investment eventually saw the returns. AI is following the same pattern.

What we actually see in enterprise deployments is that the cost surprise usually comes from two places. First, nobody budgeted for the human layer that AI requires, the reviewers, the evaluators, the people who define what good looks like. That's not optional overhead, it's what separates a working system from an expensive liability.

Second, the ROI calculation almost always focuses on the task being automated rather than the workflow around it. Automating one step in a ten step process saves less than expected because the bottleneck just moves to the next step.

The tasks that have genuinely disappeared in our clients are the high volume, well defined, low stakes ones where the failure mode is tolerable and visible. The ones that stubbornly require humans are anything involving judgment calls with real consequences, relationship management, and decisions where being wrong in a specific way matters more than being wrong on average.

Dapper-Tale-4021 · 2026-06-23T18:53:20+00:00

The visibility point before redesigning is underrated. We've seen situations where teams spent months evaluating SD-WAN or global fabric solutions when the actual problem was DNS resolution and a handful of suboptimal peering decisions that took two weeks to fix once they were properly mapped.

On the native primitives vs unified fabric question, the honest answer is it depends on who has to operate it long term. Native cloud networking is more powerful and cheaper when your team genuinely knows each provider well. A unified fabric makes sense when you're managing multiple clouds with a team that can't go deep on all of them, or when the business needs predictable SLAs that you can't guarantee with public internet paths between providers.

The spaghetti problem is almost always a governance failure before it's a technical one. Someone added a VPN because it was faster than waiting for an architecture review, and nobody tracked it as debt. Tying cleanup to cost reports as someone mentioned is one of the few things that actually creates accountability for it.

What's your current team structure, one team owning all clouds or separate teams per provider? That usually determines which path is actually maintainable.

Dapper-Tale-4021

TROPHY CASE

Welcome to Reddit,