> ## Content Index
> Fetch the complete content index at: https://www.bitsinflight.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Making AI (net)work: Six Fundamentals for a Successful AI-Integrated Network
- URL: https://www.bitsinflight.com/making-ai-network-six-fundamentals/
- Published: 2026-08-24T12:00:00.000Z
- Updated: 2026-09-16T15:36:35.000Z
- Description: A talk at a Selector event on why most AI-in-networking projects stall, and six things to get right before you pick a model. Most of them are about people and data, not technology.
- Author: Jason Gintert
- Tags: media, video, AI, network automation, Selector

*A talk given at a Selector event in New York, published 24 August 2026.*

Between the USNUA and Bits in Flight I get a lot of perspective on what network engineers actually think about AI, what they are doing with it, and where the projects go wrong. This talk pulls that together into six fundamentals, plus one I added at the last minute because it kept coming up.

## What is working, and what is not

The wins are real: rolling up alerts, getting to root cause without combing logs, overnight analysis so an operator walks in to a summary instead of a mess, incident write-ups, configuration help, and automatic documentation and runbooks from what actually changed. The failures are just as consistent. Proofs of concept run on freshly paved track and then hit the real environment. AI becomes yet another pane of glass nobody asked for. Nobody owns the project. Someone gives the platform too much access, it shoots the team in the foot, and everything stops.

## The six fundamentals

1. **Data before the model.** Unify hostnames, time zones, telemetry and your source of truth before you choose a platform. This is where I see the most projects fail, and it is why it is first. One forecast has 60% of AI projects abandoned through 2026 for lack of AI-ready data.
2. **Make AI show its work.** Understand the reasoning so you can predict it. Validate everything and keep it on probation, then spot-check, then delegate the repeatable, and even then through a deterministic automation layer rather than straight to the network.
3. **Put it where the work happens.** Chat ops in Slack or Teams, findings written into the ticket, a shim over the CLI for the people who will never leave it. Meet the team in the tools they already use.
4. **Trust has to be earned.** Nobody should be handing an LLM router logins. Let it initiate actions only through the scripts and frameworks you already trust, because uptime is the job and trust is what lets people use the tool at all.
5. **Own it and feed it.** There is no set-and-forget. Name one accountable individual, not a team. Aim for a ten-second rule on corrections so feedback is frictionless, and watch for drift and false positives before they cost you the team's confidence.
6. **Pick a win.** Choose KPIs the business understands before you start, because the person who approved the budget will ask where the savings are. Engineering value alone will not survive a belt-tightening.

**The bonus one: people do not like change.** Most failed projects die on human factors, not technology. Face it head on, show the use cases, and recruit the skeptics. The loudest "not doing that" in the room often becomes the biggest cheerleader once they are inside it.

## A 90-day shape

Lay the foundation first: align the data, baseline what normal looks like, pick the use case. Run read-only with humans in the loop. Then automate one piece of toil, measure it honestly before and after, and be willing to pivot if the gain is not there. From there, pick the next win.

The Q&A was worth staying for. Asked whether these projects come from the top or from enthusiasts, my honest answer is about half and half, and the ones that come from the top succeed when leadership over-communicates and is transparent that the goal is superpowers for the team, not replacement.

[Watch the talk on YouTube →](https://www.youtube.com/watch?v=W18ZOuv7RlU&ref=bitsinflight.com)