BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.balticnog.org//bnog-2026//ZAT9KM
BEGIN:VTIMEZONE
TZID:EET
BEGIN:STANDARD
DTSTART:20000101T000000
RRULE:FREQ=YEARLY;BYMONTH=1;UNTIL=19991231T220000Z
TZNAME:EET
TZOFFSETFROM:+0200
TZOFFSETTO:+0200
END:STANDARD
BEGIN:STANDARD
DTSTART:20011028T050000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:EET
TZOFFSETFROM:+0300
TZOFFSETTO:+0200
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20010325T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:EEST
TZOFFSETFROM:+0200
TZOFFSETTO:+0300
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-bnog-2026-AW7ZSZ@pretalx.balticnog.org
DTSTART;TZID=EET:20260923T143000
DTEND;TZID=EET:20260923T152500
DESCRIPTION:AI is already changing how networks are operated\, how traffic 
 is generated and where infrastructure is built. But for network operators\
 , the real question is not whether AI matters. It is where the value will 
 move. This panel looks at AI from three angles: as an operational tool\, a
 s a new driver of traffic and infrastructure\, and as a potential threat t
 o the traditional role of the operator.
DTSTAMP:20260920T202537Z
LOCATION:ROOM ALFA
SUMMARY:AI and Operators: Tool\, Traffic or Threat? - Zachary Smith\, Alfre
 do Giordano\, Andrian Visnevschi\, Alissa Sõtsjova
URL:https://pretalx.balticnog.org/bnog-2026/talk/AW7ZSZ/
END:VEVENT
BEGIN:VEVENT
UID:pretalx-bnog-2026-THLKBE@pretalx.balticnog.org
DTSTART;TZID=EET:20260924T123000
DTEND;TZID=EET:20260924T125500
DESCRIPTION:**2 years with an AI engineer on shift: what it fixed\, what it
  almost broke\, and the rules we wrote afterwards**\n\nWe run a managed NO
 C for ISPs\, data center operators and hosting providers worldwide. About 
 two years ago we noticed that our engineers were doing the same investigat
 ion on every shift and on every customer network\, regardless of vendor or
  topology: interface state\, optics\, neighbor tables\, routing adjacencie
 s\, prefix reachability\, logs\, then a manual correlation across four or 
 five terminals before anyone could say what broke and who was affected. So
  we built an internal AI NetOps assistant that uses the same tools our eng
 ineers already use\, runs them in parallel across the stack\, correlates t
 he output and hands the on-call engineer a root cause hypothesis with the 
 evidence attached\, together with an assessment of which services are affe
 cted.\n\nThis talk is the operational report after two years of running it
  inside a real NOC\, not a product pitch and not a lab demo.\n\nWe will co
 ver the trust ladder we enforced and why each step existed. The agent star
 ted with no CLI access at all\, reading only from monitoring\, logs\, flow
  data\, BGP telemetry and the source of truth. It was then allowed a white
 list of operational show commands. Only later\, and only for a narrow set 
 of actions\, was it permitted to propose changes\, each gated by explicit 
 human approval and a recorded audit trail. We will be honest about where t
 hat ladder stalled and which rungs we deliberately never climbed.\nWe will
  then walk through the kind of production alerts every NOC sees in its NMS
  and show how the agent actually behaves on them: a BGP session that will 
 not establish\, an IGP topology change\, an OSPF adjacency dropping\, a La
 yer 2 circuit going down. These are real cases from networks we operate\, 
 with the agent's investigation shown step by step: which data it pulled\, 
 how it correlated it\, what root cause it proposed\, and how it assessed i
 mpact at the same time. Among the cases we have already presented: a BGP f
 ailure the agent traced to a malformed attribute list while confirming in 
 parallel that redundant paths carried the traffic\; an IGP link failure it
  reasoned about from BGP-LS data without polling a single router\; an OSPF
  adjacency loss that came down to mismatched BFD timers\; a PE-CE link fai
 lure where the system separated a transceiver fault from a fiber cut and m
 apped the affected services within minutes. The NOC keeps running\, so the
  final selection will favor the most interesting cases we see between now 
 and the conference. Across these workflows\, median time from alert to ide
 ntified root cause dropped from 22 minutes to under 4.\n\nWe will also cov
 er the cases where it was wrong. Some of them are the kind of mistake any 
 engineer would catch instantly and the model did not\, and those are the m
 ost instructive\, because each one turned into a rule\, a data fix or a gu
 ardrail. We will close with the numbers across [N] production infrastructu
 res of different types: [X] alerts processed\, [Y] percent resolved withou
 t escalation\, plus screenshots of real investigations so the audience can
  judge the output for themselves.
DTSTAMP:20260920T202537Z
LOCATION:ROOM ALFA
SUMMARY:Two years with an AI engineer on shift - Andrian Visnevschi\, Nicol
 ai Moraru
URL:https://pretalx.balticnog.org/bnog-2026/talk/THLKBE/
END:VEVENT
END:VCALENDAR