Подробный разбор на испанском языке о том как внедряются агентские ИИ в госуправлении в мире: Евросюзе, Сингапуре, Великобритании и США. Много примеров включая сингапурское руководство по агентсткому ИИ для госуслуг. Полезно для всех кто занимается этим внутри госорганов потому что это не далекое, а близкое будущее когда получение госуслуг будет автоматизировано не просто через ассистентов отвечающих на простые вопросы, а на режим который есть уже у ИИ агентов и когда запрос гражданина будет итеративно обрабатываться с помощью ИИ агента который будет запрашивать людей операторов систем там где нет подключения система-система.

Для граждан это может быть как существенным прорывом, так и ситуацией когда до оператора-человека вообще не достучаться.

Там много вопросов возникает в связи с тем что ИИ агенты могут автономно делать множественные запросы в разные информационные системы и с юридическим статусом коммуникации с ними.

Но это будущее, возможно неизбежное

#ai #government

Кстати вопрос, кто уже пробовал Sourcecraft и его ИИ ассистента от Яндекса? Оно сравнимо ли с Cursor'ом или аналогичными ИИ инструментами? Стоит ли оно внимания за пределами "нужно на случай если в РФ заблокируют Github и Gitlab" или же всё пока на ранней степени зрелости/полезности/необходимости?

#questions

Хороший обзор Eight Software Markets AI That Will Transform Differently того как изменится рынок программного обеспечения в ближайшее время под воздействием развития ИИ инструментов. Из 8 ИТ рынка по настоящему радоваться могут исследователи, для них открывается бесконечный новый мир быстрого создания ПО и кода под свои задачи.

Сложнее всего будет всем кто делает корпоративные продукты, конкуренция резко усилится и ускорится, буквально во всем и тут будет ситуация что ты или быстро меняешься или уходишь на свалку истории.

Там в обзоре упоминается еще и геймдев, проекты сделанные как хобби и много чего другое.

А я вот думаю одним из важнейших глобальных изменений будет высокая скорость клонирования существующих продуктов. Чем лучше твой продукт, его API и интерфейс документированы, тем проще конкурентам воспроизвести его логику за сроки кратно меньшие чем потраченные тобой.

Можно представить, на выбор, укоренившихся вендоров ПО в некоторых отраслях и спокойно имевших свою долю рынка и неспешно на нем живших, а вдруг окажется что то что они делали пару десятилетий можно воспроизвести за 6 месяцев? за 3 месяца?

Некоторые крупные "столпы рынка" могут внезапно попадать, а суды вокруг воспроизведения API станут куда более массовыми чем сейчас.

#ai #thoughts #itmarket

В продолжение моих малореалистичных предсказаний вот краткое изложение предсказаний экспертов из Стенфорда.

Они гораздо более скучные реалистичные чем мои

ИИ в 2026: от хайпа к реальной оценке и измерению

Эксперты Стэнфорда считают, что 2026-й станет годом прагматичного подхода к искусственному интеллекту: не обещаниями и «чудесами», а оценкой реальной пользы, затрат и рисков. Вместо вопроса *«может ли ИИ что-то сделать?»* будет *«насколько хорошо, в каких условиях и для кого?»*.

AGI не появится
Общий искусственный интеллект широкого уровня всё ещё остаётся в будущем, и в ближайшем году его не ожидают.

«Суверенный» ИИ и геополитика
Страны активнее развивают собственные ИИ-экосистемы или запускают чужие модели на своих серверах, чтобы контролировать данные и снизить зависимость от крупных поставщиков.

Прозрачность и понимание
В науке и медицине усиливается внимание к объяснимости моделей — не только к результату, но и к тому, *как* система приходит к выводу.

Юридический ИИ — сложнее задач
Системы для юристов пойдут дальше простого чернового текста: научатся сопоставлять документы, синтезировать аргументы и давать оценки с привязкой к метрикам качества.

Реализм вместо пузыря
Инвестиции огромны, но эффективность ИИ в реальных процессах всё ещё умеренная. Ожидается больше тщательно измеренных данных о том, где технология действительно работает, а где — нет.

Медицина: постепенный «момент ChatGPT»
Методы самообучения и большие качественные наборы данных позволят медленным до сих пор медицинским ИИ-системам быстрее развиваться — в том числе для диагностики редких заболеваний.

Измерение воздействия на экономику
Вместо деклараций появятся «дашборды» для измерения влияния ИИ на производительность, рабочие места и отходы. Это позволит видеть результаты в реальном времени и корректировать стратегии.
—
По моему уже пришло время предсказаний в стиле Saxo Bank'а в отношении экономики, только вместо экономики предсказывать будущее ИИ (с другой стороны мы разве не подошли вплотную когда ИИ технологии и экономика становятся синонимами?)

#ai #readings

Свежий доклад от Всемирного банка GovTech Maturity Index 2025 : Tracking Public Sector Digital Transformation Worldwide с измерением уровня цифровых технологий в госсекторе.

Некоторые оценки удивляют, например, низкий уровень цифровизации в Польше и высокий уровень в Секторе Газа.

Зато Армения оценена как весьма зрелая страна в этом отношении. Хм

В рейтинге учитывается открытый код и открытые данные и ещё довольно много всего.

Сам рейтинг разделен на 4 суб-рейтинга по зрелости информационных систем, предоставлению услуг, вовлечению граждан и зрелости институтов.

#rankings #readings

Я довольно много писал про разные форматы файлов в дата инженерии и не только, с одной стороны это кажется очень внутренне-технической темой, неочевидной для тех кто не работает с данными постоянно, с другой стороны в обзоре от Andy Pavlov про СУБД за 2025 год активная конкуренция форматов явно упоминается. Потому что (внезапно!) оказалось что то как ты хранишь данные и то как хранят данные кто-то ещё и которые тебе необходимо использовать может быть как очень удобно и практично, так и создавать ничем не обоснованные дополнительные издержки.

Я привожу в пример как часто на порталах открытых данных публикуют CSV или XML файлы внутри ZIP архивов в формате: один файл - один архив. Но данные/файлы внутри ZIP архивов не приспособлены (без шаманства) для потоковой обработки. Их надо вначале распаковать куда-то как временные файлы, а потом уже обрабатывать и временные файлы удалять. Если файлы небольшие то и ладно, а если это десятки и сотни гигабайт и таких задач много, то возникает вопрос: А отчего же так? Это решается распространением датасетов не в виде ZIP архивов, а сжатием из GZip, LZMA, Zstandard, LZ4 и тд., способами и форматами сжатых данных изначально приспособленных под потоковую обработку. Собственно под такие форматы я делал iterabledata, библиотеку для Python. Она про то чтобы условно любой файл с таблицами или объектами можно было бы перебирать как это принято в Python в csv.DictReader. Последовательный перебор с возвращанием каждой записи как словаря (dict).

Но это лишь один уровень оптимизации, далее вопрос в выборочной обработке данных. Почему в какой-то момент так выстрелил довольно старый формат Parquet? Помимо хорошей компресии и возможности быстрого чтения данных он ещё и дает возможность выборочного чтения и фильтрации данных. К примеру, в отношении XML файлов это уже не работает, в отношении JSON, с большими ограничениями (для JSONl да, в остальных случаях нет) и так далее. А ещё есть огромное число форматов имеющих предметное и отраслевое применение где всё что можно - это, либо считывать их в память целиком, или перебирать содержание по каждой записи.

Вот примеры таких форматов: WARC (файлы веб архивов), PCAP (файлы перехвата сетевого трафика), SAS (файлы статпакета SAS), и еще много что: BSON, KML, GML, XLS, ODS и так далее. Реально огромное число форматов не поддаются фильтрации без загрузки в память или не через фильтрацию при тотальном переборе.

Поэтому когда доходит до их обработки, приходится преобразовывать их полностью или частично в parquet. К примеру, для WARC файлов я всегда их преобразую в один или несколько parquet файлов с метаданными, а оригинальные файлы рассматриваю как контейнеры для контента. И это я не сам придумал, а подсмотрел когда-то у Common Crawl, они поступают аналогично поскольку без этой процедуры собирать статистику сложно, надо перелопачивать каждый WARC файл, а это гигабайты-терабайты-петабайты.

Однако и сам формат Parquet'а неидеален и об этом регулярно пишут в разных местах и появляются такие форматы как Lance, Vortex, Nimble, Vortex, FastLanes и другие. Пока они довольно редки в открытом доступе, но постепенно проявляются. Впрочем parquet оказался достаточно эффективным чтобы эта замена длилась ещё какое-то количество леь

А вот чтобы я бы предсказал так то что грядет тренд на parquet'изацию данных, когда просто сильно удобнее распространять их в структурированном подобным образом виде. Возможно через рассмотрения parquet файлов как контейнеры, а возможно как файлы-сателлиты с метаданным к файлам контейнерам. К примеру, можно вполне заменить VCF файлы (генетика) на Parquet или файлы LDIF (директории пользователей LDAP) на Parquet или файлы KML и GML (геоданные) и тд.

#thoughts #data #dataengineering #fileformats

Чем следователь (дознаватель) отличается от археолога ? Археолог копает чтобы поместить результаты в музей/архив, а следователь чтобы найти улики преступления. Но существенная часть их работы пересекается, оба копаются в земле, инвентаризируют и изучают результаты. Некоторые инструменты (лопаты, щётки) практически идентичные.

Применительно к цифровым артефактам ситуация очень похожая. Работа цифрового архивиста и цифрового дознавателя во многом пересекается.

Цифровые архивисты работают с архивами, как правило, связанными с общедоступными массивами цифровых материалов или организационными, они изучают, зачастую, очень унаследованные данные, файлы, электронную почту и тд. в целях инвентаризации и обеспечения доступа. При этом им необходимо уметь понимать форматы в которых эти материалы хранятся, иметь инструменты которые позволяют их просматривать или преобразовывать и так далее. Увлекательное дело для всех кто любит копаться в цифровом мусоре ценных артефактов прошлых поколений.

Цифровые дознаватели работают почти всегда с личными и корпоративными данными, электронной почтой, перехваченными сообщениями и файлами полученными из устройств пользователей и серверов - образов дисков и памяти компьютеров, телефонов, планшетов и так далее. Инструменты цифрового дознания формируют отдельную экосистему, они, по большей части (но не все), проприетарны и оперируют извлечением структурированных знаний из установленного ПО и памяти. Например, извлекая данные контактов и сообщений мессенжеров, почты, последних скачанных файлов и тд.

И там и там все сохраняется в базы с метаданными оформленным по своим правилам. Тоже пересекающиеся по логике и содержанию.

Удивительное дело, так почему не дознавателей не учат на архивистов, а архивистов на дознавателей? 🙈

Впрочем на цифровых архивистов вообще мало где учат, в России точно нет, вообще это только в ряде стран такая явная специализация есть. А цифровые дознаватели не везде сформировались как явная профессия и чаще совмещается или декларируется как киберследователь (ИТ-детектив) и в компаниях по кибербезопасности их больше чем в правоохранительных органах (а может быть и нет).

#thoughts

Cursor выпустил гайд с лучшими практиками по использованию ИИ агентов в разработке. Рекомендации все довольно понятные, я бы даже сказал что очевидные для опытных разработчиков, но могут быть не настолько очевидными для кого-то ещё.

Важный акцент там на стадии планирования и вопросам к ассистенту до реализации фич или исправления багов.

А я бы добавил к этому следующее:
1. Планирование через OpenSpec или его аналоги. Очень хорошо структурирует процесс проектирования и коммуникации с ИИ агентом. Для сложного и унаследованного кода - это просто необходимо. В принципе разделять планирование и реализацию, на стадии планирования не меняется код, а результаты - спеки и планы.
2. Cursor и аналогичные инструменты (Antigravity, Copilot и тд.) могут выполнять роль инструментов исследовательской поддержки и аналитики. Например, формируz отчеты по конкурентам, проектируя инструменты бенчмарков с ними, подготовка аналитики по разным функциям, проектирование верхнеуровневой архитектуры и тд.
3. ИИ ассистент - это не только объект проверки (а не кривой ли код он написал?), но и сам является контуром контроля качества. Поэтому на каждой итерации внедрения фич необходим контур создания и проверки тестов, линтинга кода, обновления документации и тд. Это частично решается уже сейчас на стадиях планирования и спеков, но опыт показывает что явное указание этих обязательных проверок дает больше гарантии что код будет не поломан и документация будет актуальной.
4. Инструменты для разработки вполне способны не только писать код, но и писать документы. Подход такой же может быть как к репозиториям кода с использованием спецификаций, планирования и тд. Иначе говоря при проектировании больших ИТ продуктов можно создать отдельный репозиторий с архитектурой продуктов и от него создавать все остальные. Например, если надо условно с нуля сделать продукт у которого есть фронтэнд, бэкэнд, REST API, SDK, интеграционные модули и тд., то вместо того чтобы все засовывать в один репозиторий или сразу разбивать на множество, имеет смысл собрать архитектурный репозиторий с документами.

#ai #coding #thoughts #readings

Кто знает, это правда или фэйк?

Интересный взгляд на ИИ разработку в тексте про Gas town от Steve Egge. Много уникальной терминологии так что сразу ещё один текст Gas town decoded

Подход интересный, но к терминологии надо привыкнуть ибо сложное описание процессов через большое число новых понятий.

Почитать точно стоит всем кто проектирует ПО

#readings #aiagents

Разные мысли вслух:
1. Термин "большие данные" в 2026 году выглядит анахронизмом, а экономика больших данных особенно. Когда слышу его от кого-либо то вот прямо таки ощущаю что человек находится вне контекста и, либо не понимает предметной области (увы), либо довольно долго был от нее оторван. Условно нет никакой "экономики больших данных", есть экономика данных, но и она, условно, слепляется с ИИ стартапами и ИИ экономикой. В этом есть странное смешение хайпа, реальности и страха потому что это гораздо большие изменения цифровых экосистем чем что-то ещё.
2. Евросоюз запустил публичное обсуждение стратегии импортозамещения и снижения зависимости от США стратегии открытой цифровой экосистемы которая должна помочь цифровому суверенитету ЕС и которая формируется из открытости кода, открытости данных и так далее. Мне такой подход нравится больше чем российское импортозамещение, но реалистичность реального цифрового суверенитета для ЕС, по моему, невелика. Однако если ВЫ резидент ЕС и работаете с открытым кодом и данными, то почему бы не поддержать такое хорошее дело?

#opendata #bigdata #thoughts #opensource #eu

🇺🇸 Выход США из ЮНЕСКО: что это значит для открытой науки?

Выход США из ЮНЕСКО и растущее расхождение американского законодательства с ценностями открытой науки вызывают у экспертов опасения относительно инфраструктуры открытой науки в США. Хотя многое еще неясно, старший научный сотрудник Луиза Безуиденхаут и старший научный советник Нидерландской комиссии по делам ЮНЕСКО Джон Верриет считают, что глобальные последствия для открытой науки могут быть весьма серьезными.

Более подробная информация здесь.

Полезные ссылки про данные, технологии и не только:
- Open Responses открытая спецификация на API для LLM на базе OpenAI Responses API. Вообще API OpenAI и так уже было стандартом де-факто, а тут уже и формализированный и описанный стандарт. Не вижу какой-то конкретной организации за его разработкой, похоже на частную инициативу
- Using AI as a Design Engineer о работе дизайн инженера с использованием ИИ, многое похоже на разработку ПО в целом, но есть свои особенности вроде интеграции с Figma MCP
- Can A.I. Generate New Ideas? может ли ИИ генерировать новые идеи? Статья в NYT, под пэйволом. Краткое изложение можно прочитать тут
- How UK museums are embracing citizens’ assemblies to help frame their futures интересное явление когда британские музеи начали создавать общественные советы которые должны помогать им определять их будущее

#uk #museums #ai #llms #design #ideas #readings