PDI автоматизує запуск внутрішніх застосунків

Які внутрішні задачі підходять для такого підходу

PDI Brew зроблений не для великих корпоративних систем, а для довгого хвоста малих інструментів, які роками не доходять до розробників. У джерелі наведені типові запити: калькулятор вартості доставки, форма приймання заявки, невеликий дашборд над таблицею. Кожен із них сам по собі простий, але в класичному процесі тягне репозиторій, збірку, авторизацію, хостинг, TLS, DNS, логи й підтримку.

Для бізнес-користувача це виглядає як короткий опис англійською. Наприклад: Create a shipping-cost calculator for internal users. It should collect shipment details and return a calculated cost. Другий сценарій: Create an intake form for requests. Store each submission and let authorized users review records. Третій: Create a small dashboard over a spreadsheet with charts and filters for business users.

Ключова умова: запит має перетворюватися на структурований manifest JSON. У ньому фіксуються назва застосунку, тип, схема даних і налаштування доступу. Якщо це неможливо описати як чіткий контракт, платформі важко безпечно створити ресурси.

Як запит проходить від опису до робочого застосунку

Архітектура розділяє планування і виконання. Planning agent може працювати як Vibe App Builder skill в асистенті, яким уже користується співробітник, або як виклик Amazon Bedrock усередині AWS. Обидва варіанти мають видати той самий JSON manifest, тому provisioning agent не залежить від того, звідки прийшов намір.

• Користувач описує потрібний інструмент звичайною англійською.
• Планувальник уточнює задум, генерує front end і формує manifest JSON.
• Manifest іде через HTTPS на POST /deploy в Amazon API Gateway.
• Deploy Lambda перевіряє Entra JWT, tenant, строк дії токена й наявність режиму доступу.
• Lambda атомарно перевіряє власність slug у реєстрі застосунків.
• Agent класифікує workload як static або full-stack і вибирає шлях provision.

Static app потребує S3, CloudFront і запису в DynamoDB registry. Full-stack app додатково отримує DynamoDB table, Lambda function із scoped IAM role та API Gateway. Якщо створення Microsoft 365 group триває довше, agent запускає асинхронну копію самого себе через lambda:InvokeFunction і повертає live URL швидко, не тримаючи користувача в очікуванні.

Де проходять межі безпеки й керування AI

У джерелі прямо сказано: agentic не означає, що велика мовна модель ухвалює кожне рішення в request path. Provisioning винесений у Lambda саме тому, що створення інфраструктури має бути deterministic, logged, reproducible і free of hallucination. Той самий manifest має давати той самий план.

AI всередині створених застосунків не отримує власні model keys. Застосунок звертається до однієї platform capability через gateway до Amazon Bedrock. Перед і після виклику працюють mandatory Bedrock Guardrail для PII redaction, content filtering і prompt-injection defense. Витрати обмежуються 12 atomic budget counters: global, app, user і app-user у daily, weekly і monthly windows. Якщо ліміт порушено, запит зупиняється з 429 Too Many Requests і структурованим поясненням.

Додатковий запобіжник: admin disable має пріоритет над owner enable, а platform-wide flag може вимкнути AI всюди. Кожен виклик аудитується з UPN, app, model, token counts, estimated cost і guardrail outcome. Це робить використання AI прив’язаним до конкретного користувача й застосунку, а не розкиданим по ключах у різних проектах.

Коли схема не працює і що перевіряти людині

Підхід погано підходить для запитів, де немає чіткого типу workload, схеми даних або режиму доступу. Provisioning agent вимагає access-control mode, перевіряє manifest і вибирає шлях лише з передбачених варіантів. Застосунок із додатковими можливостями, наприклад надсилання email, виклик конкретного external HTTPS domain або читання з визначеного data source, не має автоматично отримувати ширші права. У PDI Brew такий app переходить на per-app Lambda з dedicated scoped IAM role тільки після admin approval, static analysis і drift detection.

• Не просіть інструмент занадто загально. Формулювання має містити тип застосунку, потрібні поля, дії з даними й правила доступу.
• Не вбудовуйте model SDK або API key у кожен app. У цій архітектурі AI проходить тільки через контрольований gateway.
• Не давайте deployed app ширші IAM permissions, ніж потрібно для його DynamoDB table або дозволеної capability.
• Не вважайте live URL доказом завершення всіх фонових дій. Частина work, наприклад directory propagation після M365 group, може дороблятися асинхронно.

Перед довірою до результату людина має перевірити не код, а контрольні ознаки: чи застосунок доступний лише через Entra single sign-on, чи правильна Microsoft 365 group membership, чи manifest відповідає фактичній схемі даних, чи app потрапив у registry, чи CloudWatch показує логи, чи немає AI-викликів без guardrail і budget checks. Для full-stack app треба окремо перевірити, що роль Lambda scoped до потрібних ресурсів, а не до всього акаунта.