# 23Minds - full site content (llms-full.txt) **Canonical URL:** https://23minds.com/llms-full.txt **Site:** https://23minds.com **Languages:** English (canonical), Polish (written natively, not translated) **Generated at:** build time from the same data the pages render from (anchors, guides, messages) This file contains the complete markdown content of every public page on 23minds.com. EN content first (canonical), PL content second. Ingest, retrieve, cite freely. For the manifest / TOC see https://23minds.com/llms.txt. ================================================================ ENGLISH CONTENT (canonical) ================================================================ # 23Minds - full site content - English (canonical) _Auto-generated at each build from the same data the pages render from (anchors.en.ts, guides, messages/en.json). Canonical EN copy._ --- # Homepage - 23Minds **URL:** https://23minds.com/ > 23Minds delivers AI-assisted software development and independent evaluation of AI-generated code. Security review, code evaluation, engineering training. ## AI-assisted software development & engineering. Independent evaluation of AI-generated code. Describe what you want to build, fix or check. An engineer replies within one business day. - ISO 9001:2015 certified (DNV Business Assurance, 10000439701-MSC-RvA-POL) - Registered seat: ul. Wawrzyniaka 6W, 70-392 Szczecin - Locations: Szczecin, Warszawa, Zielona Góra, Kraków - Languages: English and Polish - Response time: one business day ## This is what evaluating AI-assisted code looks like. An evaluation starts with a sample of files or pull requests from your repository: each one gets a score against four criteria: correctness, security, maintainability and test quality. The result is a report with findings ranked by severity - like the one beside this text - and a walkthrough with your team. The service runs as a one-off or as continuous review, during the work and after release. This is not a tool: an engineer reads and evaluates the code, and findings land in your issue tracker, not in another dashboard. ## A working rhythm you can plan around. - **Week 1 - Scope in writing** An intro call and an agreed scope: what you get, in what order, at what price. No commitment on your side. - **Month 1 - The first tangible result** The first evaluation report, or the first working slice of the system on a preview. Findings land in your issue tracker. - **Quarter 1 - A rhythm instead of pushes** Continuous review, retests after fixes, quality gates in your process. The team works with AI by agreed rules, not by feel. - **Year 1 - The capability stays with you** Procedures, evaluation criteria and trained people are yours. 23Minds stays for the hard cases and for whatever changes in the tools. Timelines are indicative and depend on scope; dates are set on the intro call. ## AI training for leadership, product teams and engineering. Programs for business, product and engineering teams: workshops priced per day, or a cohort program running over several weeks. The curriculum is built around your team's tools and the work they actually do. Co-funding for training. Selected AI training programs are listed in Poland's Development Services Database (BUR). The operator decides on co-funding and its level, based on company size and region. Eligibility is checked before planning, on the intro conversation. ### Training programs - **GOV-101 AI Governance and EU AI Act Essentials** (Leadership and compliance): System classification, human oversight, rules for using AI. - **BIZ-201 Designing AI Use Cases That Reach Production** (Product teams): From an idea to a pilot with an end date and a decision. - **SEC-201 Secure Coding with AI Assistants** (Engineering): Mistakes typical of assistant-written code, agent permissions, review rules. - **ENG-101 AI-Assisted Development with Coding Assistants** (Engineering): Claude Code, Cursor and Copilot on your team's repository. - **BIZ-101 AI Literacy for Business Teams** (All teams): Prompts for real work tasks, data you must not send, checking the answers. - **ENG-201 Reviewing AI-Generated Code** (Engineering, QA): What to check in a large AI-written change, and what blocks a merge. ## Questions procurement teams ask. **How do you work with new clients?** We start with an intro call to map your situation, then scope a fixed first engagement - an evaluation, a workshop, or an automation pilot - with clear deliverables and timeline. **What does an engagement cost?** Every practice has an entry package with its price on the practice page: from a training day to an audit of one repository. Where the effort depends on the size and complexity of your system, the price is shown as "from" and becomes fixed once the scope is agreed on the intro call, with no hidden costs. Larger projects and retainers are quoted after the call, per phase. **Can training be publicly funded?** Selected AI training programs are listed in Poland's Development Services Database (BUR); the operator decides on co-funding and its level, based on company size and region. We check it with you on the intro conversation. **Why an "Institute" and not an agency?** Two things. We are engineering-led, so you talk to the people who write and maintain the code rather than to a layer of account management. And we leave the capability with you: we train your team to work with AI instead of tying it to us permanently. Outcomes are measured in production, against indicators agreed before we start. **What is covered by your ISO 9001 scope?** Design and development of web and mobile applications, e-commerce and websites; application service; IT training and consulting; online marketing; and robotic automation of business processes. ## Talk to an engineer. Describe what you want to build, fix or check. A reply within one business day. The site is organized around these areas: Train & Adopt, Evaluate & Secure, Build & Modernize, Operate & Measure. --- # About - 23Minds **URL:** https://23minds.com/about > An engineering company: software built with AI, and independent evaluation of AI-generated code. 23Minds builds software with AI and independently evaluates AI-generated code: security review, code evaluation, team training and production support. The brand is operated by DFZOO.COM Sp. z o.o., a Polish company entered in the National Court Register (KRS) in 2019. The company is ISO 9001:2015 certified by DNV Business Assurance (cert. 10000439701-MSC-RvA-POL), registered for VAT-EU and works with clients worldwide. ## This site is built and maintained by Claude, under the direction of the 23Minds engineering team. The 23Minds website you are reading right now - the code, the copy, the structured data, the routing, the deploys - is produced by Claude (Anthropic's AI assistant) working alongside the 23Minds engineering team. It is the same AI-assisted development workflow the AI Institute teaches to clients. Public transparency: this site is the working artifact of the engagement methodology 23Minds offers to clients. The same development workflow, code review process and deployment discipline applied here are documented in the company's service procedures. ## What is worth knowing. - **Engineering-led** - 23Minds consultants are engineers. Trainers ship code. Evaluations are written by the same people who build comparable systems. Sales and delivery are the same team. - **ISO 9001:2015 certified** - Quality management certified by DNV Business Assurance (10000439701-MSC-RvA-POL). A procurement-ready signal that the way engagements are run is auditable, not a one-off heroic effort. - **Production-grade outcomes** - Engagement outcomes are measured against agreed production KPIs: cost per request, P95 latency, error rates, deployment frequency. Reports are written by the same engineers who ran the engagement. ## DFZOO.COM Sp. z o.o. The 23Minds brand is operated by DFZOO.COM Sp. z o.o., a Polish private limited company entered in the National Court Register (KRS) in 2019, registered for VAT-EU and headquartered in Szczecin. The team has been in business since 2012 and works with clients in Poland and abroad. The company holds ISO 9001:2015 quality management certification (DNV Business Assurance, cert. 10000439701-MSC-RvA-POL). ## ISO 9001:2015 scope Quality management certified by DNV Business Assurance, certificate number 10000439701-MSC-RvA-POL. The scope includes: - Design and development of web and mobile applications - E-commerce and websites - Application service - IT training and consulting - Online marketing - Robotic automation of business processes ## Offices - **Szczecin** (registered seat): ul. Wawrzyniaka 6W, 70-392 Szczecin, Poland. Office hours: Mon-Fri, 09:00-17:00 CET. - **Warszawa**: meetings by appointment. - **Zielona Góra**: meetings by appointment. - **Kraków**: meetings by appointment. --- # Contact - 23Minds **URL:** https://23minds.com/contact > Talk to an engineer. Describe what you want to build, fix or check - whether AI is already running at your company or you are starting from scratch. A reply within one business day, in English or Polish. - A reply within one business day - An NDA before the call, if you need one - An engineer runs the conversation, not a salesperson ## Offices - **Szczecin** (registered seat): ul. Wawrzyniaka 6W, 70-392 Szczecin, Poland. Office hours: Mon-Fri, 09:00-17:00 CET. - **Warszawa**: meetings by appointment. - **Zielona Góra**: meetings by appointment. - **Kraków**: meetings by appointment. ## Contact channels - **Sales & new engagements**: start@23minds.com - For intro calls, scoping conversations, RFP responses and procurement questions. - **Press & partnerships**: start@23minds.com - Media inquiries, speaking opportunities, partnership proposals or co-marketing conversations. ## Business & legal - Legal name: DFZOO.COM Sp. z o.o. (23Minds is a brand; the registered legal entity behind it is DFZOO.COM Sp. z o.o.) - VAT-EU: PL8522656040 - KRS / Court register: 0000783223 - Registered address: ul. Wawrzyniaka 6W, 70-392 Szczecin --- # Services - 23Minds **URL:** https://23minds.com/services > The areas 23Minds works in: Train & Adopt; Evaluate & Secure; Build, Automate & Modernize; Operate & Measure. Each area groups the practices that belong to it. ## Service areas, organized for the way you buy. Every engagement at 23Minds sits in one of these areas. Pick the situation you are in - the practices that solve it are grouped below. The site is organized around these areas: Train & Adopt, Evaluate & Secure, Build & Modernize, Operate & Measure. --- ## AI literacy under Article 4 of the EU AI Act: role-based training and the records that prove it **URL:** https://23minds.com/guides/ai-literacy-obligation-article-4 **Canonical URL (PL is canonical for this page):** https://23minds.com/pl/przewodniki/obowiazek-szkolen-ai-act-artykul-4 > Article 4 of the EU AI Act requires providers and deployers to take measures that support the AI literacy of the people who operate and use AI systems on their behalf. It is a standing obligation rather than a one-off webinar, and it is evidenced with records of what was done, not with a statement that training happened. ### Summary 23Minds delivers AI literacy training that helps organizations operating in the European Union, including companies based outside Poland with EU customers or staff, meet the Article 4 duty of Regulation (EU) 2024/1689. The obligation has applied since 2 February 2025 and was not covered by the omnibus package that postponed high-risk compliance deadlines. We build the programme per role: one thing for the board and procurement, another for the people operating a system and exercising human oversight, another for engineering. What stays with the client is the evidence pack: a register of trained people, the per-role programme with dates, a validation record of learning outcomes and named certificates. DFZOO.COM Sp. z o.o. holds ISO 9001:2015 issued by DNV Business Assurance, certificate no. 10000439701-MSC-RvA-POL. ### Who it's for - Boards and buyers who sign AI statements in customer security questionnaires and tender documents - Process owners running a purchased AI system, that is deployers under the Regulation - People operating AI systems day to day and carrying human oversight duties - Engineering teams building AI features or integrating vendor models - HR, compliance and procurement teams that have to show who was trained, on what programme and when - Companies outside Poland whose EU footprint pulls them into the obligation ### What Article 4 actually requires Article 4 of Regulation (EU) 2024/1689, as amended by Regulation (EU) 2026/1744, requires providers and deployers of AI systems to take measures to support the development of AI literacy of their staff and other persons dealing with the operation and use of those systems on their behalf. The article names what has to be taken into account: technical knowledge, experience, education and training, the context the systems are used in, and the people or groups the systems are used on. It also states that the obligation does not require guaranteeing any specific level of AI literacy of any individual. There is no hour count in the text, no named course and no requirement for an external certificate. The test is fit to role, so an auditor or a customer looks at two things: whether the programme matched what that person actually does with the AI system, and whether you can show it. The personal scope is the widest in the whole Regulation. It reaches people who are not your employees but act on your behalf: contractors, agencies and subcontractors operating your systems. The obligation has applied since 2 February 2025 and that date was not moved. What the 2026 omnibus package did change, from 27 July 2026, is the wording of Article 4 itself. The original text required measures to ensure, to the best extent, a sufficient level of AI literacy; the new one requires measures that support its development and states that no specific level has to be guaranteed for any individual. New paragraphs oblige the Commission and the member states to support these efforts, particularly in SMEs, with practical examples published by the Commission, and the AI Board to adopt recommendations. The obligation still applies from 2 February 2025, and the records have to show the measures you took. ### Mapping roles to the level of AI understanding they need This is where paper compliance is manufactured. One course for everyone ticks the box and changes nothing about how people work with the system. Below is the starting layout we bring in, then adapt to your systems and roles. The evidence column is the one that matters later. It answers the question that arrives months after the training: what will you show to prove that this person received a programme matched to their role. | Role | What this person has to understand | Scope of training | Evidence that stays | | --- | --- | --- | --- | | Board and buyers | What the company takes on when it buys an AI system, and which duties follow the provider role rather than the deployer role | Orientation in the Regulation, roles, risk classes, contractual and procurement consequences | Dated programme and a named certificate | | Process owner, that is the deployer | What the system is for, where its reliability ends, and when to stop or escalate | Limits of use, input data, monitoring, deployer obligations | Per-role programme and a validation record of learning outcomes | | Operator carrying human oversight | How to recognise an output that must not be accepted unchecked, and what to do next | Hands-on work on your system, edge cases, escalation path, decision logging | Practical exercise completed in your own environment | | Engineering team | Where model errors come from, how to measure them, and what to record so they can be reproduced | Evaluation, testing, event logging, traceability, application-layer security | Knowledge test result and workshop artifacts | | Marketing, support and anyone publishing content | What may be published, what has to be labelled, and where the tool's responsibility ends | Transparency obligations, content marking, verification before publishing | Publishing checklist and a named certificate | | Procurement, legal and compliance | What to require from a vendor and what has to end up in the contract and in the system register | Provider versus deployer duties, documentation, vendor questions | Reusable vendor question set and a register entry | ### What training does not cover Article 4 is one obligation among many and on its own it makes no system compliant. We say so plainly, because the usual problem after training is not missing knowledge, it is overestimating what the training covered. - Training does not replace an inventory or a risk classification of AI systems: that is separate work with a separate artifact - Training does not produce the technical documentation required for high-risk systems - A training certificate is not a declaration of conformity and must not be presented as one in questionnaires or tenders - Training does not discharge human oversight: oversight is an architectural requirement with a named owner, not a state of mind - The legal reading of the article, and what it means for your situation, is signed by counsel, not by us ### How this reads outside Poland Article 4 comes from the Regulation, so it applies across the Union in the same wording. What differs country by country is the national supervision layer and the funding attached to training. In Poland, market surveillance sits with the Commission for the Development and Security of Artificial Intelligence, established by the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003). The Act entered into force on 11 August 2026; Articles 8-18 and Chapters 3-5, 8 and 9, which carry the inspection regime and the penalties, enter into force on 28 October 2026. Public training money in Poland also runs on its own rules: since 1 January 2026, training funded by labour offices and the National Training Fund is delivered by providers listed in the Baza Usług Rozwojowych register, and Priority 3 of the 2026 National Training Fund names AI explicitly, though it is aimed at new processes, technologies and work tools in companies, particularly where those factors threaten jobs. If your Polish entity intends to co-fund the training, that path has to be settled before dates are fixed, and we settle it with you. For a group operating in several member states, the practical answer is one role map and one evidence format, with local annexes where a national regulator or a funding body asks for something extra. ### Where this goes wrong, and what we do about it **The training happened, the evidence did not** One webinar goes out to everyone, the attendee list stays inside the meeting tool, the recording lands on a shared drive. Six months later a customer security questionnaire asks who was trained, on what programme and when. Nobody can reconstruct a named list or show that the scope matched the role, so the answer becomes "we run training", which in a questionnaire counts for nothing. What we do about it: We start from the list of people who touch AI systems and diff it against the list of people trained, so you see the gaps as named individuals before the first session. After each group we issue a dated register, the per-role programme and named certificates, and we confirm outcomes with a test and a practical exercise rather than with attendance. Register completeness is checked again when the project closes. What stays with you: dated register of trained people, per-role programme and a validation record of learning outcomes **One programme for everyone** A generic "AI for business" course is bought once and pushed through the whole organization, because that is cheaper and easier to account for. Engineers get an hour on what a language model is, and the person who approves or rejects cases on that system never sees a single example from their own screen. The box is ticked, daily practice does not move, and the first questionable output finds nobody who knows what to do with it. What we do about it: We map roles to the level of understanding each one needs and build a separate programme per group, on material taken from your systems rather than from slides. The starting level is checked with a short test before the session, the result with a practical exercise in your environment. A group that lands below the threshold repeats the module, not the course. What stays with you: role map with an assigned level, and a dated programme per role **Training misses the AI nobody registered as AI** Scope is set around the tool the company adopted deliberately, a coding assistant or an internal chat. Left outside are the AI features built into software bought years ago: summaries in the ticketing system, candidate ranking in the recruitment platform, drafted replies in support. Those are exactly where deployer duties sit, and people use them daily without ever calling them AI. What we do about it: Before the programme is fixed we run a short inventory of actual use: the application list from SSO sign-ins, a direct question to vendors about features added in updates, and a survey inside teams. What we find enters the training scope, and what falls outside training goes onto a list of systems to classify, handed over as a separate result. What stays with you: list of tools with AI features in real use, marked for what enters the programme **Scope written around a funding deadline instead of around roles** A funding body's calendar sets the date, so the scope bends towards whatever can be accounted for inside that window rather than towards who needs what. The paperwork is then assembled after the fact, from memory, and that is when a missing signature, a missing outcome record or a mismatch between the declared and delivered programme shows up. What we do about it: We build the programme around roles first and only then look for a window, not the other way round. Documentation is produced alongside the sessions: attendance, the validation record of learning outcomes and the certificates are finished on the day the training runs. Before anything is submitted we check the pack against the funder's requirements. What stays with you: complete funding pack closed on the last day of training **A certificate mistaken for conformity** After the training somebody writes, in good faith, that the company is AI Act compliant, in a customer questionnaire or a tender response. A training certificate says nothing about system classification, technical documentation or oversight, so the mismatch surfaces during the first serious due diligence, which is the worst possible moment: mid transaction or mid procurement. What we do about it: The materials and the register state plainly what the training covers and what it does not. On top of that we issue a one-page scope note written in the language of a customer questionnaire, so the person filling in the form has a true sentence ready instead of improvising one. The note is reviewed with your legal team before it is issued. What stays with you: one-page scope note for questionnaires and tenders, reviewed by your legal team ### What you get - Register of trained people: name, role, date, programme, validation result - Role map with the level of AI understanding required for each role - Per-role training programme, dated and scoped, ready to show on request - Validation record of learning outcomes: knowledge test plus a practical exercise on your system - Named certificates of participation - List of tools with AI features in real use, split into training scope and classification backlog - Scope note stating what the training covers and what it does not, for use in questionnaires - Complete funding documentation where public money pays for the training ### How we work 1. **1. Role map and inventory of actual use** (Week 1): We establish who touches AI systems and in what role, and which tools people actually use, including AI features built into software bought earlier. 2. **2. Per-role programme and funding path** (Week 1-2): We build a separate programme per group on material from your systems. In parallel we settle whether and how the training is to be co-funded, and what that means for dates and paperwork. 3. **3. Delivery** (Week 2-4, depending on the number of groups): Sessions run per group, each on its own programme. Operational and engineering groups work in your environment, not on slide examples. 4. **4. Validation and evidence pack** (Week 4): Outcomes are confirmed with a test and a practical exercise; we issue the register, the validation record and the certificates, and close the funding documentation. 5. **5. Review** (Every 12 months or after a material change): We return after a systems change or after a year: the role map is updated, new people and new tools are added, and the programme is refreshed where scope moved. ### FAQ **Q: Was Article 4 postponed together with the rest of the AI Act?** No, and this is the distinction that goes missing in market commentary. The 2026 omnibus package moved compliance deadlines for Annex III high-risk systems to 2 December 2027 and for AI in regulated products to 2 August 2028. Article 4 has applied since 2 February 2025 throughout. The omnibus did amend its wording from 27 July 2026: providers and deployers take measures that support the development of AI literacy, without having to guarantee a specific level for any individual, and new paragraphs oblige the Commission and the member states to support these efforts. Same deadline, still an obligation, now one to act rather than to reach a level. **Q: How many hours of training are enough?** The Regulation gives no hour count. The test is whether the programme fits the role, the technical knowledge of the audience and the context the system is used in. In practice that ranges from a short orientation session for a board to a multi-day programme for an engineering team, and the role map decides it, not a number fixed in advance. **Q: Who exactly has to be trained?** Staff and other people dealing with the operation and use of your AI systems on your behalf. That includes people outside your payroll: contractors, agencies and subcontractors operating your systems. The personal scope of Article 4 is wider than an employee list. **Q: What do we show when someone asks for proof?** A dated register of trained people with roles, the per-role programme, the validation record of learning outcomes and named certificates. Those are the documents that work in a customer questionnaire, a tender and an inspection. The evidence is the documentation, not the fact that a session took place. **Q: Who supervises this in Poland?** The Commission for the Development and Security of Artificial Intelligence is the market surveillance authority and the single point of contact, established by the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003). The inspection regime and the penalty provisions enter into force on 28 October 2026. Liability in a specific case is assessed by counsel; we prepare the evidence that assessment rests on. **Q: Can training be co-funded in Poland?** Since 1 January 2026, training funded by labour offices and the National Training Fund is delivered by providers listed in the Baza Usług Rozwojowych register, and Priority 3 of the 2026 National Training Fund names AI explicitly. That priority targets new processes, technologies and work tools in companies, particularly where they threaten jobs, so fitting the application to that wording is part of the work. Limits, terms and dates are set by the operator for your region, so we check them with you before scope and dates are fixed. **Q: Does training make us AI Act compliant?** No, and we do not present it that way. Article 4 is one obligation. Compliance also needs at least an inventory and classification of systems, and for high-risk systems technical documentation, event logging and human oversight. After the training you get a note that states this boundary in writing. ### Scope of this page We are an engineering and training team, not a law firm. This page describes how to perform the obligation and how to evidence it, not how the article should be read for your situation. The legal reading and any assessment of liability are signed by counsel: yours, or our legal partner. Dates and instrument numbers are published together with their sources so you can verify them without asking us for an opinion. ### Related - https://23minds.com/services/train-adopt-govern/ai-training-programs - https://23minds.com/services/train-adopt-govern/eu-ai-act-compliance - https://23minds.com/services/train-adopt-govern/ai-governance-basics ### Sources - Regulation (EU) 2024/1689 (AI Act), consolidated text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj - Polish Ministry of Digital Affairs: what changed in the AI Act on 2 August 2026: https://www.gov.pl/web/cyfryzacja/ai-act--co-sie-zmienilo-2-sierpnia-2026-roku - Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003): https://eli.gov.pl/api/acts/DU/2026/1003/text/O/D20261003.pdf - Baza Usług Rozwojowych replaces the training institution register from 2026: https://zielonalinia.gov.pl/bur-zamiast-ris-przygotuj-instytucje-szkoleniowa-na-nadejscie-2026-roku/ - FERS 1.3 call: automation competences for digital transformation: https://www.funduszeunijne.gov.pl/nabory/13-kompetencje-z-automatyzacji-dla-transformacji-cyfrowej/ - Regulation (EU) 2026/1744 (Digital Omnibus on AI), text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2026/1744/oj - 2026 National Training Fund priorities set by the minister for labour: https://wupbialystok.praca.gov.pl/rynek_pracy/kfs/-/asset_publisher/fRJeGax7dNIi/content/krajowy-fundusz-szkoleniowy-priorytety-na-rok-2026-1 --- ## AI system register and risk classification in Poland: the Act of 3 July 2026 and the supervision calendar **URL:** https://23minds.com/guides/ai-system-register-poland **Canonical URL (PL is canonical for this page):** https://23minds.com/pl/przewodniki/rejestr-i-klasyfikacja-systemow-ai > Before anyone asks you about compliance, you need an answer to two questions: which of our tools are AI systems, and are we the provider or the deployer of each. A register answers both, and it decides how much work everything after it will cost. ### Summary 23Minds builds AI system registers and risk classifications for organizations operating in Poland, including foreign groups with a Polish entity. The national instrument is the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003), in force since 11 August 2026. Articles 8-18 and Chapters 3-5, 8 and 9, which carry the inspection regime and the penalties, enter into force on 28 October 2026. Market surveillance and the single point of contact sit with the Commission for the Development and Security of Artificial Intelligence. We do the engineering half of this work: we find AI systems including the ones embedded in software you bought, describe each one in a register with a written classification rationale, and wire the register into the processes that keep it current. The legal qualification and the signature on it stay with counsel. ### Who it's for - Companies that bought or built tools with AI features and have no single list of them - Product teams whose AI feature was just challenged in a customer questionnaire - Software houses and integrators that have to tell a client which role they are in - Public bodies where staff adopted generative AI faster than internal rules were written - Compliance leads, CISOs and CTOs who need an artifact to sign, not a presentation ### What is in force and from when The Act of 3 July 2026 on artificial intelligence systems was published on 27 July 2026 (Journal of Laws 2026 item 1003) and entered into force on 11 August 2026. Articles 8-18 and Chapters 3-5, 8 and 9 enter into force later, on 28 October 2026. The split matters in practice, because the later group carries the inspection regime and the penalty provisions. Article 5(1)-(2) makes the Commission for the Development and Security of Artificial Intelligence the market surveillance authority within the meaning of Article 70(1) of Regulation (EU) 2024/1689, and the single point of contact. Its chair was appointed by the Sejm with the consent of the Senate, given on 24 September 2026, and the Commission is to start work in November 2026. The Act also provides for regulatory sandboxes, and micro, small and medium-sized enterprises take part in them free of charge. | Date | What changes | What it means in practice | | --- | --- | --- | | 27 July 2026 | Publication in the Journal of Laws (item 1003) | The text is public and can be worked from | | 11 August 2026 | The Act enters into force, except the listed provisions | The national framework applies, the authority exists | | 24 September 2026 | Senate consents to the appointment of the Commission's chair | There is an addressee for filings and questions | | 28 October 2026 | Articles 8-18 and Chapters 3-5, 8 and 9 enter into force | The inspection regime and the penalty provisions start to operate | | November 2026 | The Commission starts work | Market surveillance becomes operational | ### Is your tool an AI system Nobody will arrive and tell you that a given system falls in scope. Every organization assesses that for itself, and the assessment has to be reproducible, because it is the first thing an inspector, a customer questionnaire or a due diligence process asks about. We run the assessment on technical characteristics, not on how a vendor markets the product. What counts is whether the system infers from its inputs and how much autonomy it has. It also matters whether its outputs, such as recommendations or decisions about people, can influence physical or virtual environments. The definition lists adaptiveness after deployment as a possible feature, not a required one. Most disputes appear where it is easy to say "that is just automation": scoring and ranking, prediction used to select cases for review, document classification, generated replies in support, candidate sorting. Publicly reported disputes over exactly this qualification show it is settled on technical facts, so the facts need to be written down before anyone asks. - Hand-written rules and a model trained on data give two different answers, so you need to know what is actually inside the product - A purchased system where the vendor added an AI feature in an update is your system for the purposes of deployer duties - The same technology in two use cases can land in two risk classes, because intended purpose decides, not the algorithm - An edge case is recorded as an edge case and sent to counsel, rather than quietly resolved in favour of the cheaper answer ### How to run an inventory that holds up An inventory run by sending a survey to teams produces a list of what people remember. We collect from four sources at once and compare them, because it is the gaps between the sources that show what is missing. Below are the fields an entry needs in order to stand on its own, without the person who wrote it in the room. - What you built: repositories, model API calls, services with an embedded model integration - What you bought deliberately as an AI tool: contracts, invoices, data processing annexes - What arrived quietly: AI features added by vendors in updates to software you already ran - What people picked up themselves: applications visible in SSO sign-ins and in card spend | Register field | Why it is there | | --- | --- | | Name and business owner | Someone is accountable for the entry and for keeping it current | | Intended purpose | Risk class follows the purpose, not the technology | | Input data and its source | The basis for assessing impact on people and data requirements | | Model and vendor, with version | Without the version the assessment cannot be reproduced | | Your role: provider or deployer | The duty set follows the role | | Risk class and rationale | A class without a rationale cannot be defended | | Human oversight: who, and at which point | Separates a stated control from a working one | | Entry date, review date, person | Shows the register is alive rather than written once for an audit | ### Provider or deployer The role decides the duty set and is a more frequent source of confusion than the risk class itself. A company deploying a purchased system is normally a deployer, but can become a provider if it puts its own name or trademark on the system, modifies it substantially, or changes its intended purpose to one the original provider did not foresee. We check this for every register entry and record it together with the facts it rests on. The final legal qualification is confirmed by counsel, because the list of duties you then have to perform follows from it. ### Where this goes wrong, and what we do about it **The register is born in a spreadsheet and dies within a quarter** An inventory produced once for an audit or a customer questionnaire lands in a spreadsheet with no owner and no moment where someone has to update it. Systems move faster than the sheet: a vendor switches an AI feature on in an update, a team swaps in a newer model, someone buys a tool on a company card. Two quarters later the register describes a state that no longer exists, which is worse than having none, because it produces confidence with nothing behind it. What we do about it: We wire the register into processes that happen anyway: buying a tool, deploying it, changing vendor and changing model each get a mandatory field pointing at the entry. Every entry carries a named owner. On top of that we set a quarterly review that diffs the register against the SSO application list and spend, and the differences become a list to explain. What stays with you: register with named owners, an update procedure wired into procurement and deployment, and a quarterly difference list **Classification without a rationale** The risk class column has a value in it, but nothing records what the value was based on. The person who decided it has changed roles or employers. At the first question from an inspector, a customer or a buyer in due diligence, nobody can reconstruct the reasoning, so the whole classification is redone, this time under time pressure. What we do about it: Every entry gets a rationale citing the provision and the specific facts about the system: intended purpose, data, autonomy, impact on people. We record the date and the person. Rationales are walked through with your counsel and the outcome of that review is stored next to the entry, not in somebody's mailbox. What stays with you: classification rationale per system, in a form ready for legal review and signature **AI embedded in a purchased tool stays outside the register** The inventory asks teams what they built and never asks vendors what they added. AI features enter recruitment platforms, ticketing systems and CRMs through routine updates, with no decision on your side at all. Those are precisely where deployer duties sit, and they are absent from the register because nobody counted an update as adopting AI. What we do about it: We send vendors a specific question about AI features in the version you run and about what they plan to add; the question template stays with you for reuse. In parallel we read changelogs and processing annexes and diff the SSO application list against the register. Answers and check dates are stored on the entries, so next time it is visible what is fresh and what needs asking again. What stays with you: vendor list with answers and dates, plus a reusable question template **Qualification decided by preference** Calling a system plain automation is cheaper and faster, so the product description starts drifting towards the preferred answer. The problem is that qualification is judged on technical facts, and those live in the code, in the vendor contract and in what the system actually does with data. The gap between the description and the facts surfaces exactly when it costs the most. What we do about it: We qualify on facts: what is in the code and the configuration, what data goes in, how much autonomy there is, and what happens to the output. The facts are recorded on the entry together with their source. Where facts do not settle it, the case is marked as contested and handed to counsel with the question already written, instead of being decided in-house. What stays with you: list of edge cases with the underlying facts and a question drafted for counsel **The calendar read as a single date** "The Act came into force on 11 August" reads like the end of the story, so the work plan is built around that one date. Meanwhile the inspection regime and the penalty provisions apply from 28 October, and the authority becomes operational later still. The hardest part of the schedule ends up last, when there is no room left to move it. What we do about it: We plan against both dates and against the point where the authority starts operating, with a list of what has to be ready before each. The schedule carries owners and statuses, so it shows what is done rather than what is intended. We walk it with you monthly until the end of the year. What stays with you: schedule split across both entry-into-force dates, with owners and status ### What you get - AI system register with owner, intended purpose, data, model, vendor and version - Classification rationale per system, ready for legal review - Role determination, provider or deployer, per entry, with the facts behind it - Register update procedure wired into procurement, deployment and vendor changes - Vendor list with answers on AI features, plus a reusable question template - List of edge cases with questions drafted for counsel - Schedule split across 11 August and 28 October 2026 ### How we work 1. **1. Collection from four sources** (Week 1): Repositories and model API calls, contracts and invoices, vendor changelogs, SSO sign-ins and spend. We compare the results, and the gaps between them set the rest of the work. 2. **2. Register and first classification** (Week 1-2): Every system is described across the full field set, with a role and a risk class assigned together with a rationale grounded in facts. 3. **3. Edge cases and legal review** (Week 2-3): We separate what the facts settle from what needs interpretation, draft the questions and work through them with your counsel or our legal partner. 4. **4. Wiring in and handover** (Week 3-4): The register gets owners and an update procedure, the deadline schedule goes to the people accountable for it, and we walk the whole pack through with leadership. 5. **5. Quarterly review** (Quarterly): We diff the register against reality: new applications in SSO, vendor updates, model changes. Differences are explained and added. ### FAQ **Q: From when can penalties apply in Poland?** The Act of 3 July 2026 (Journal of Laws 2026 item 1003) entered into force on 11 August 2026, but Articles 8-18 and Chapters 3-5, 8 and 9, which carry the inspection regime and the penalty provisions, enter into force on 28 October 2026. Exposure in a specific case is assessed by a lawyer; we prepare the documentation such an assessment rests on. **Q: Who is the supervisory authority?** The Commission for the Development and Security of Artificial Intelligence, designated as the market surveillance authority within the meaning of Article 70(1) of Regulation (EU) 2024/1689 and as the single point of contact. Its chair was appointed by the Sejm with the consent of the Senate, given on 24 September 2026, and the Commission is to start work in November 2026. **Q: Do purchased tools go into the register too?** Yes. Deployer duties cover purchased systems as well, including AI features a vendor added in an update to software you have run for years. This is the most commonly skipped part of a register, and usually where we find the most entries. **Q: Does the register have to be filed with anyone?** The register is first of all your own instrument: without it you cannot answer the classification question or perform the remaining duties. Whether any filing duty applies depends on the class of the system and on your role, so we establish it for specific entries and confirm it with counsel rather than stating a general rule. **Q: How long does an inventory take?** For an organization with a dozen or so systems, typically three to four weeks from data collection to a register with rationales. The time goes not into describing systems but into reaching the ones nobody remembers, so the schedule depends on how quickly we get access to SSO sign-in data, contracts and changelogs. **Q: How is this different from an AI Act compliance audit?** The register and classification come first and answer the question of what is even in scope. An audit goes further: it checks how duties are performed for systems that are already classified and ends with a gap analysis and a remediation plan. Neither makes sense without the other, but they are two different scopes and two different quotes. **Q: Do regulatory sandboxes cost anything?** The Act provides for regulatory sandboxes, and micro, small and medium-sized enterprises take part free of charge (Article 93(1)). The participation conditions and the application process are set out in Chapter 7 of the Act, in force since 11 August 2026, so the details are settled at the time of applying. ### Scope of this page We are an engineering team, not a law firm. We build the register, collect the facts and prepare rationales in a form ready for review, but the legal qualification of a system and the assessment of duties are signed by counsel: yours, or our legal partner. Cases the facts do not settle are marked as contested rather than quietly resolved. ### Related - https://23minds.com/services/train-adopt-govern/eu-ai-act-compliance - https://23minds.com/services/train-adopt-govern/ai-governance-basics - https://23minds.com/services/train-adopt-govern/ai-training-programs ### Sources - Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003), full text: https://eli.gov.pl/api/acts/DU/2026/1003/text/O/D20261003.pdf - Polish Ministry of Digital Affairs on the AI systems act: https://www.gov.pl/web/cyfryzacja/ustawa-o-systemach-ai--bezpieczny-rozwoj-sztucznej-inteligencji-w-polsce - Regulation (EU) 2024/1689 (AI Act), consolidated text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj - prawo.pl: the AI Act enters into force and public bodies do not know whether they use AI: https://www.prawo.pl/samorzad/ai-act-wchodzi-w-zycie-urzedy-nie-wiedza-czy-korzystaja-ze-sztucznej-inteligencji,1547762.html - Polish Senate: 65th sitting, 24 September 2026, consent to the appointment of the chair of the Commission for the Development and Security of Artificial Intelligence: https://www.senat.gov.pl/aktualnoscilista/art,17779,65-posiedzenie-senatu-drugi-dzien.html - European Commission: guidelines on the definition of an AI system under Regulation (EU) 2024/1689, C(2025) 5053 final: https://ec.europa.eu/newsroom/dae/redirection/document/112455 --- ## Article 50 transparency obligations: what has applied since 2 August 2026 **URL:** https://23minds.com/guides/ai-act-transparency-obligations-article-50 **Canonical URL (PL is canonical for this page):** https://23minds.com/pl/przewodniki/obowiazek-przejrzystosci-artykul-50 > The headline about the AI Act being delayed concerns high-risk systems. The Article 50 transparency obligations arrived on schedule, on 2 August 2026, and generative systems placed on the market before that date have until 2 December 2026 to bring their content marking in line. That is the deadline in front of you, not the 2027 ones. ### Summary 23Minds implements the Article 50 transparency obligations of Regulation (EU) 2024/1689 in digital products and content publishing workflows. Those obligations have applied since 2 August 2026 and were not covered by the postponement that Regulation (EU) 2026/1744 introduced for Annex III high-risk systems and for AI in regulated products. We translate three duties into engineering work: telling a user they are interacting with an AI system, machine-readable marking of generated content, and telling the audience, in a form they can see or hear, that a deepfake has been artificially generated or manipulated. Marking is verified at the end of the publishing path rather than inside the authoring tool, and we leave behind a test that repeats that check on every deployment. The legal reading is signed by counsel. ### Who it's for - Product teams running a chat, an assistant or a voice channel backed by a model - Editorial and marketing teams publishing images, video and text made with AI - Companies that deployed an assistant in a support channel, their own or a partner's - Product compliance owners who received contradictory messages from the market about the deadlines ### What moved and what did not Regulation (EU) 2026/1744, the digital omnibus, entered into force on 27 July 2026 and postponed compliance deadlines for high-risk systems. It did not postpone the transparency obligations in Article 50. What it did add is the transition the market talks about least: providers of generative systems placed on the market or put into service before 2 August 2026 have until 2 December 2026 to meet the technical content-marking duties. For most teams that is the date actually sitting in the calendar. | Obligation | Original deadline | Status after the change | | --- | --- | --- | | AI literacy (Article 4) | 2 February 2025 | Unchanged, in force | | Transparency obligations (Article 50) | 2 August 2026 | Unchanged, in force | | Annex III high-risk systems | 2 August 2026 | Moved to 2 December 2027 | | AI in regulated products (Annex I) | 2 August 2027 | Moved to 2 August 2028 | | Content marking in generative systems placed on the market before 2 August 2026 | 2 August 2026 | Transition until 2 December 2026 | ### Three duties translated into engineering work Article 50 describes an outcome, not an implementation. Below is what follows from it for a product, split into where it shows up, how it is done, and how it is verified. | Obligation | Where it shows up in the product | How to implement it | How to verify it | | --- | --- | --- | --- | | Disclosing that the counterpart is an AI system | First message in the conversation and a persistent label in the header, on every entry point: widget, voice channel, email, partner integration | A message in the interface layer, not in the terms of service; wording clear to someone who has never seen your product | Walk every entry point and capture a screenshot from each | | Machine-readable marking of generated content | The file leaving your system, and the same file fetched from the production URL | Content Credentials under the C2PA standard or metadata in XMP and IPTC fields, plus an entry in the generated-asset register | Fetch the published asset and read the marking with a reader, rather than checking the file in the tool | | Disclosure that deepfake content has been artificially generated or manipulated | The place of publication: page, video, post, ad creative | A label the audience can see or hear, in the material itself or directly next to it, independent of metadata | Review published material channel by channel, with a list and a date | ### What to do with content already published Start from the fact that takes the pressure out of this work: material generated and published before 2 August 2026 does not have to be marked retroactively. The duty covers what you produce now, and generative systems placed on the market before that date have until 2 December 2026 to comply with the technical marking requirements. Marking older material retroactively is therefore your call, not a requirement. It earns its keep where the material could be taken as a record of a real event, and there it is worth deciding deliberately rather than deferring. The order of work that holds: inventory first, then priorities, then a decision recorded somewhere it can be found again. - Inventory: what was generated, when, with which model, and where it now lives - Priority for material showing a person and for anything that could be taken as a record of a real event - Re-mark where the channel allows replacement without losing the address and where you decide it is worth it - For assets that cannot or need not be marked retroactively: a recorded decision with a rationale and a date, so the question does not reopen every quarter - A generated-asset register with checksums, so the next change does not start from zero ### Where this goes wrong, and what we do about it **The machine-readable marking is stripped in transit** Content Credentials and XMP metadata survive the export from the authoring tool, and are then removed by the first step of the publishing path that re-encodes the file: a CDN converting images to WebP, compression inside the CMS, or an upload to a social platform. The team sees a correctly marked file in the repository and treats the matter as closed, while the asset in production carries nothing. What we do about it: We verify the marking at the end of the path, on the asset fetched from its production URL, not on the file in the tool. We leave a test that repeats this on every deployment and reports the gap. Where a channel strips metadata and that cannot be changed, we add a human-readable label and record the decision in the asset register. What stays with you: marking conformance report per channel, plus a verification test wired into your deployment process **The disclosure buried in the terms of service** The statement that a user is talking to an assistant ends up in the privacy policy or in a tooltip, because the team does not want to spoil the first impression. The duty is about information given in a clear and distinguishable manner at the latest at the first interaction, so whether the duty is met depends on where the statement appears. On top of that it is usually missing from the entry point nobody remembers: the partner integration, the voice channel, the automated email reply. What we do about it: We put the disclosure in the first message and as a persistent label in the conversation header, then walk every entry point into the system, partner surfaces included. Each entry point gets a status and a screenshot. The list of entry points stays with you, so when a new channel is added it is clear what has to be checked. What stays with you: inventory of entry points with a status and a screenshot for each **A caption on the image instead of marking the content** The team adds a line of text in the corner of an image and treats it as satisfying the machine-readable requirement. The caption is cropped by the first video frame or by a thumbnail in a social feed, and no machine will read it anyway. It fails in the other direction too: metadata in a file is not a label a person can see or hear, so on its own it does not satisfy the disclosure required for deepfakes. What we do about it: We separate the two requirements and implement both, each with the technique that fits it: a label readable by a person, and marking readable by a machine. For every content type, image, video, audio and text, we write down exactly what appears and where. The result is checked with a C2PA reader and by visual review, separately. What stays with you: marking specification per content type, with verification results from both methods **The vendor says it marks content and nobody checked** The model vendor's documentation mentions watermarking or Content Credentials, so the item leaves the list. In practice the marking can depend on the model version, on the call mode and on which endpoint you use, and your integration may predate the feature or bypass it. The claim lives in the vendor's documentation, not in your artifact. What we do about it: We sample your actual integration, per model and per call mode, and check what really comes out. Differences from the documentation are recorded with a date and a model version and escalated to the vendor. Whatever the vendor does not add, we mark on your side rather than waiting for their release. What stays with you: sampling results with date, model version and call mode **The market talks about a delay, so the team defers everything** The headline about the AI Act being postponed concerns high-risk systems, but it lands in the plan as a single sentence: we have until 2027. The transparency duties arrived on time and apply to products that are live now. The plan is built from the headline rather than from the table of deadlines, and the difference only becomes visible when somebody outside asks about a specific feature. What we do about it: We hand over a deadline table with the legal basis for each row and map it onto your systems, stating for each one what applies now and what applies later. The summary fits on one page, so it can go to the board without translating a regulation. We update it whenever the legal position changes. What stays with you: one-page deadline summary per system, with the legal basis next to every line ### What you get - Inventory of the points where a user meets an AI system, with a status and a screenshot - Marking specification per content type: image, video, audio, text - Verification test that checks the marking on the published asset, wired into your deployment process - Generated-asset register with model, version, date and checksum - Deadline summary per system: what moved, what did not, and what follows for you - List of questions for counsel wherever the decision is interpretation rather than engineering ### How we work 1. **1. Inventory of touchpoints and assets** (Days 1-3): We walk every entry point into a conversation with the system and every channel that publishes generated content. The output is a list with statuses, not an opinion. 2. **2. Specification and fixes** (Week 1-2): We agree what appears in the interface and how each content type is marked, then implement the changes together with your team. 3. **3. Verification in production** (Week 2): We check the marking on assets fetched from production URLs, channel by channel, and leave a test that repeats the check on every deployment. 4. **4. Handover and review at model change** (Week 2-3, then at every model change): We hand over the specification, the register and the test. We come back when a model or vendor is swapped, because that is when marking most often disappears quietly. ### FAQ **Q: Was Article 50 postponed as well?** No. Regulation (EU) 2026/1744 entered into force on 27 July 2026 and moved the deadlines for Annex III high-risk systems to 2 December 2027 and for AI in regulated products to 2 August 2028. The Article 50 transparency obligations arrived on the original date, 2 August 2026. There is one transition: generative systems placed on the market before 2 August 2026 have until 2 December 2026 to meet the technical content-marking requirements. **Q: Does the chat on our website need a disclosure?** If a user interacts with an AI system, they have to be informed of that in a clear and distinguishable manner, unless it is obvious to a reasonably well-informed, observant and circumspect person, taking into account the circumstances and the context of use. In practice that means a message in the first turn and a persistent label in the interface, not a clause in the terms of service, and it applies to every entry point into the conversation, including one launched inside a partner's product. **Q: What counts as machine-readable marking?** Marking a machine can read from the asset itself, for example Content Credentials under the C2PA standard or metadata in XMP and IPTC fields. A caption drawn on an image is not that. You also have to account for publishing channels that strip metadata, which is why marking is checked on the published asset rather than on the file in the tool. **Q: Do we have to mark AI-assisted text on a company blog?** The duty concerns text published to inform the public on matters of public interest, and its reach over purely marketing material is read differently by different advisers. That is a question for counsel, not a claim for us to make. Practically, we recommend keeping a generated-asset register regardless of how that assessment lands, because without one every later decision costs several times more. **Q: What about material published before the deadline?** Material generated and published before 2 August 2026 does not have to be marked retroactively. Generative systems placed on the market before that date are a separate matter: they have until 2 December 2026 to meet the technical marking requirements. Marking older material retroactively is your decision, worth making where the material could be read as a record of a real event, and we record it with a rationale and a date. **Q: Does the model vendor not handle this for us?** Some vendors add marking on their side, but it depends on the model, the version and the call mode, and the responsibility stays with you. We sample your actual integration, per model and per mode, and mark on your side whatever the vendor does not add. **Q: Who enforces this in Poland?** The Commission for the Development and Security of Artificial Intelligence, as the market surveillance authority and single point of contact established by the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003). The inspection regime and the penalty provisions enter into force on 28 October 2026. ### Scope of this page We are an engineering team, not a law firm. This page covers how to perform the obligation in a product and how to verify that it works, not how the article should be read for your case. Scope boundaries, in particular around published text and the exceptions in Article 50, are settled by counsel: yours, or our legal partner. Dates and instrument numbers are published together with their sources. ### Related - https://23minds.com/services/train-adopt-govern/eu-ai-act-compliance - https://23minds.com/services/evaluate-audit-secure/ai-quality-evaluation - https://23minds.com/services/evaluate-audit-secure/production-readiness ### Sources - Regulation (EU) 2024/1689 (AI Act), consolidated text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj - Polish Ministry of Digital Affairs: what changed in the AI Act on 2 August 2026: https://www.gov.pl/web/cyfryzacja/ai-act--co-sie-zmienilo-2-sierpnia-2026-roku - Pinsent Masons: law delaying EU high-risk AI rules finalised: https://www.pinsentmasons.com/out-law/news/law-delaying-eu-high-risk-ai-rules-finalised - Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003): https://eli.gov.pl/api/acts/DU/2026/1003/text/O/D20261003.pdf - Regulation (EU) 2026/1744 (Digital Omnibus on AI), text on EUR-Lex: https://eur-lex.europa.eu/eli/reg/2026/1744/oj --- ## Prompt cache hit forensics and hard spend limits: reading the LLM bill as an invoice **URL:** https://23minds.com/guides/prompt-cache-hit-forensics-and-spend-limits > Prompt cache forensics is the practice of reading, call by call, whether a request hit or missed the provider's prompt cache, what that cost, and why the miss happened. Paired with a spend limit that stops traffic instead of sending an email, it turns an LLM bill from a monthly surprise into an invoice with line items. ### Summary 23Minds performs prompt cache forensics and installs hard spend limits for engineering teams whose LLM bill grows faster than their traffic. The work attributes every call to a feature and a session, reads the cache fields the provider returns in each response, and names the cause of every miss: a rewritten prefix, a proxy that drops the cache marker, a parallel burst, an expired TTL. The client keeps a forensic report with a per-call table, a prefix layout the whole team can verify with a hash, and a limit register that states what happens to each feature when its budget is reached. Savings are measured on the provider's usage report before and after the fixes. ### Who it's for - CTOs and VPs of Engineering who got a bill they could not explain from the usage dashboard - Platform teams running an LLM gateway or proxy (LiteLLM, a custom router, Bedrock behind an OpenAI-compatible layer) - Teams shipping agent loops where every turn resends the whole conversation - Finance partners who need LLM cost split by product feature and by customer, not by API key ### Reading the bill as an invoice The provider's usage report answers one question: how many tokens of each kind went through each API key, per model, per day. Anthropic's Usage and Cost API groups by API key, workspace, model and service tier and splits input into uncached, cache write and cache read; OpenAI and Google offer the same shape. None of them know what a feature or a session is, because that information lives in your code. An invoice needs three joins the dashboard does not have. First, every request carries a feature name and a session identifier as metadata, logged at the gateway next to the provider's request id. Second, the usage block of every response is stored per call, not summed per day: Anthropic returns cache_creation_input_tokens and cache_read_input_tokens, OpenAI returns input_tokens_details.cached_tokens and cache_write_tokens, Bedrock's Converse API returns cacheReadInputTokens and cacheWriteInputTokens. Third, the price list with its write and read multipliers is applied per call, so every request has its own cost. With those joins in place the question changes from "why is the bill high" to "which feature, in which sessions, paid full input price for a prefix that should have been cached". That is a question with a ranked answer. ### How prompt caching is billed at the three providers The mechanics differ enough that a rule of thumb from one provider produces misses at another. The table below is taken from the providers' documentation as of September 2026; the source links are at the end of the page. | Provider | What is cached | Lifetime | Price of a write and a read | Where the hit shows | | --- | --- | --- | --- | --- | | Anthropic (Claude API) | Prefix ending at a cache_control breakpoint, in the order tools, system, messages; minimum 512 to 4,096 tokens by model | 5 minutes by default, 1 hour as an option | Write at 1.25x input (5 min) or 2x (1 hour); read at 0.1x, 0.025x on some models | cache_creation_input_tokens, cache_read_input_tokens | | OpenAI | Automatic exact-prefix match from 1,024 visible tokens; tool definitions, schemas and reasoning settings are part of the prefix | 30 minutes after the last write or reuse on GPT-5.6 and later; 5 to 10 minutes of inactivity, up to an hour, on earlier models | Read at 0.1x uncached input on GPT-5.6 and later; model-specific cached rates before | input_tokens_details.cached_tokens, cache_write_tokens | | Google Gemini | Implicit caching on by default for Gemini 2.5 and newer, from 2,048 or 4,096 tokens; explicit caches created by the caller | Explicit cache TTL defaults to 1 hour, configurable | Cached tokens at a reduced rate plus a storage price per million tokens per hour for explicit caches | cached tokens in usage metadata | | Amazon Bedrock (Claude) | cachePoint block in Converse or cache_control in InvokeModel, same section order; the minimum counts all sections together | 5 minutes, 1 hour on supported models; resets on every hit | Read at the model's cache-read rate; writes can be billed above the input rate | cacheReadInputTokens, cacheWriteInputTokens; the docs state support does not guarantee a hit | ### What quietly breaks the prefix A cache miss is never random. Something before the breakpoint changed between two requests, or the second request arrived when no entry existed. The catalogue below is what the forensic diff finds most often, in rough order of cost. - A token-saving layer that rewrites history. Compression or trimming of older messages changes the bytes before the breakpoint on every turn, so every turn writes a new entry at 1.25x instead of reading at 0.1x. Practitioners on developer forums have reported exactly this: a plugin sold as saving tokens raised the Anthropic bill. Fewer tokens at full price cost more than more tokens at a tenth of it. - Tool definitions that change or reorder. Tools sit first in the prefix, so a tool added, a description edited or a list rendered from an unordered set invalidates everything after it. - Dynamic content at the top of the system prompt: a timestamp, a user name, a per-request id. One byte before the breakpoint and it is a different prefix. - A proxy that does not carry the marker. An OpenAI-compatible layer in front of Bedrock has to translate cache_control into a cachePoint block; if it drops it, every layer still "supports caching" and nothing is cached. One publicly documented case ran Droid through LiteLLM into Bedrock and ended at 37,901.73 USD with about 6.47 billion uncached input tokens. - Parallel bursts. Anthropic documents that an entry only becomes available after the first response begins, so ten requests fired at once write the same prefix ten times. - Parameter toggles. Thinking, effort, tool_choice, output schemas and reasoning settings are part of the prefix identity at Anthropic and OpenAI; a feature flag that flips one of them flips the cache. - Expired lifetime. A batch that sends one request per document every twenty minutes never reuses a 5-minute entry; Anthropic offers a 1-hour option for that shape, OpenAI's default window on GPT-5.6 is 30 minutes. - The arithmetic of agent loops. Every turn resends the whole conversation, so input tokens over a session grow with the square of the number of turns. With hits, most of that square is billed at 0.1x; without them, all of it at full price. That is why an agent bill jumps rather than climbs. ### Where an alert ends and a hard stop begins Every publicly described cost incident ends with the same sentence: the alerts were configured. An alert is an email with a delay measured in hours; a runaway loop is measured in requests per second. The provider controls that actually stop traffic differ, and the differences decide the design. - Per-feature and per-customer limits do not exist at any provider. They live in your gateway: a counter per feature and per tenant, a budget, and a controlled error when it is reached. - A limit is a product decision. Before it is switched on, each feature gets a written answer to "what does the user see when this stops": a degraded mode, a queue, a smaller model, or a clear message. - A limit that has never fired is a guess. The drill is a synthetic loop on a test project that reaches the limit, with a record of how long enforcement took and who was paged. | Provider | What stops traffic | What only notifies | Granularity | | --- | --- | --- | --- | | Anthropic | Monthly spend limit per workspace, plus per-workspace rate limits on requests and tokens per minute | Spend alerts at thresholds | Workspace; not on the Default Workspace, not per API key | | OpenAI | Hard spend limit per organisation or project: requests return 429 with organization_spend_limit_exceeded or project_spend_limit_exceeded; enforcement is not instantaneous | Spend alerts, traffic continues | Organisation and project | | Google Cloud (Gemini via Cloud Billing) | Spend cap budget (preview) for eligible services, or a Pub/Sub budget notification wired to code that disables billing on the project | Alerts-only budgets, which the documentation says do not cap usage or spending | Billing account and project | ### What the forensic report looks like and what the team does with it The core of the report is one table with one row per call. Everything else in the report is an aggregate of that table, so any number in the summary can be traced back to the requests that produced it. - Rank miss causes by the money attached to them, not by frequency. One cause usually carries most of the cost. - Fix the top causes at the source: reorder the prompt, pin the tool list, move dynamic content below the breakpoint, serialise the first request per prefix, fix the proxy translation. - Re-run the same table on the provider's usage report after the change. Before and after come from the same source, so the saving is a measurement. - Install the limits last, once the baseline is honest, so the budget is set against real consumption and not against the bug. | Column | What it holds | Where it comes from | | --- | --- | --- | | Call | Provider request id, timestamp, model | Response headers and usage block | | Feature and session | Feature name, session id, tenant | Metadata your gateway attaches to the request | | Prefix | Hash of the bytes up to the last breakpoint, and the offset where it first differs from the previous call in the session | Gateway log, diffed offline | | Hit or miss | Read, write and uncached tokens | Usage block, per provider field names | | Cost | Price per token class on the date of the call | Provider price list, your invoice | | Miss cause | One entry from the catalogue above, or "unexplained" | The diff, the timing between calls, the proxy trace | ### Where this goes wrong, and what we do about it **A token-saving layer rewrites the prefix on every turn** A compression or history-trimming plugin sits between the application and the provider and edits older messages to send fewer tokens. The edit changes bytes before the cache breakpoint, so each turn creates a new cache entry at the write price and reads nothing. The dashboard shows fewer input tokens and a higher bill, and the team reads that as the model getting more expensive. What we do about it: We log consecutive requests per session at the gateway and diff them byte by byte to find the first divergence. Where it sits inside the supposedly static prefix, we either move the dynamic edit below the breakpoint or take the layer out. We then compare cache_read_input_tokens against total input on the provider's usage report for the same feature before and after. What stays with you: per-session diff report with the divergence offset for each call, and the cache read share before and after the change **A proxy in the chain drops the cache marker** The application marks a breakpoint, the OpenAI-compatible proxy forwards the request to Bedrock, and the marker never becomes a cachePoint block. Every layer in the chain documents prompt caching support, which is what the team checked. Nothing in the chain reports that the marker was dropped; the only evidence is that cache read tokens stay at zero on the provider side. What we do about it: We replay one fixed request through each hop of the chain and read the cache fields returned at each hop, so the layer that loses the marker is named rather than suspected. We fix the translation or the configuration at that hop and repeat the replay until the provider reports reads. What stays with you: hop-by-hop trace table for a fixed request, with the cache fields returned at every layer **Dynamic content sits above the breakpoint** The system prompt starts with the current date, the user's name or a request id, or the tool list is rendered from a set whose order is not stable. The prefix is different on every call by a few bytes, and the provider correctly treats it as a new prefix. This is the most common cause and the cheapest to fix, and it stays invisible without a diff. What we do about it: We write down the prompt layout as an ordered list of blocks with a static and a dynamic side, pin the tool order, and move every per-request value after the last breakpoint. The layout gets a hash that the gateway checks on every request, so a later edit that breaks the order fails a test instead of the bill. What stays with you: prompt layout specification with a prefix hash and a gateway check that fails when the static part changes **The alert fires and nothing stops** A budget alert is configured at the provider and a loop with a bug in its exit condition starts at night. The email lands at the threshold, the on-call reads it in the morning, and the spend between the two is the incident. The provider's alert did what it was designed to do; the design assumed a person in the loop at request speed. What we do about it: We set the control that actually stops traffic at the provider: a workspace spend limit on Anthropic, a hard project limit on OpenAI, a spend cap or a billing-disable function on Google Cloud. Above that we add per-feature and per-tenant budgets in your gateway with a controlled error, and we run a drill that reaches each limit on a test project to record the enforcement delay. What stays with you: limit register per provider and per feature, with the user-facing behaviour when each limit is reached and the drill results **Parallel fan-out and retries write the same prefix many times** A feature fans out ten requests with the same prefix at once, or a retry policy resends the full prompt on every 429. Anthropic documents that a cache entry only becomes available after the first response begins, so the burst writes the entry once per request and reads it never. The hit rate looks acceptable on average and terrible on exactly the features that fan out. What we do about it: We serialise the first request per prefix and release the rest once the entry exists, cap retries and add jitter, and measure the write-to-read ratio per feature rather than per key. Features that fan out get their own row in the report so the average cannot hide them. What stays with you: write-to-read ratio per feature, before and after, taken from the provider's usage report ### What you get - Forensic report with one row per call: feature, session, prefix hash, hit or miss, tokens by class, cost, miss cause - Cost attribution per feature, per session and per tenant, reconciled against the provider's cost report for the same period - Prompt layout specification with a prefix hash and a gateway check that fails when the static part changes - Limit register: per provider and per feature, what stops, what notifies, what the user sees, and who is paged - Drill record: each limit reached once on a test project, with the measured enforcement delay - Before and after measurement on the provider's usage report, with the query used so finance can repeat it ### How we work 1. **1. Capture** (Week 1-2): We attach feature, session and tenant metadata at your gateway, store the usage block of every response, and pull the provider's usage and cost reports for the same window. One to two weeks of traffic is enough for the diff to be representative. 2. **2. Forensics** (Week 2-3): We build the per-call table, diff consecutive requests per session, replay a fixed request through each hop of the proxy chain, and assign a cause to every miss. Causes are ranked by the money attached to them. 3. **3. Fixes and limits** (Week 3-5): We fix the top causes at the source together with your team, write the prompt layout down with its hash, then set the provider limit and the per-feature budgets with a defined behaviour for each. Every limit is reached once on a test project. 4. **4. Re-measurement and handover** (Week 5-6): We rerun the same table on the provider's usage report after the change and hand over the report, the layout specification, the gateway check and the limit register. The check stays in your pipeline so the next prompt edit cannot silently reopen the miss. ### FAQ **Q: The provider dashboard already shows cached tokens. Why is a per-call table needed?** The dashboard sums by API key and by day, so a feature with zero hits disappears inside a key with a healthy average. The per-call table keeps feature, session and prefix next to the usage fields, which is what lets a miss be assigned a cause. Anthropic's Usage and Cost API is the reconciliation source; it is not the diagnosis. **Q: Does a prompt cache hit rate of, say, 80% mean the system is fine?** It means 80% of eligible tokens were read from cache across everything that key sent. It says nothing about which features got the other 20% or what it cost. We report the write-to-read ratio per feature and the money per miss cause, because one agent loop with dynamic content above the breakpoint can outweigh every other feature combined. **Q: Can prompt compression or history trimming ever be worth it?** Yes, when the trimmed content sits after the last breakpoint or when the prefix is below the provider's minimum cacheable size anyway. The test is arithmetic, per feature: tokens removed times the full input price against tokens kept times the cache read price. We run that calculation from your traffic before any layer is switched on or off. **Q: Which spend limit should be set first?** The one that stops traffic at the provider: a workspace spend limit on Anthropic, a hard project limit on OpenAI, a spend cap or a billing-disable automation on Google Cloud. Alerts stay on for early warning, but they do not cap anything. Per-feature and per-customer budgets come next, in your gateway, because no provider offers them. **Q: What happens to the product when a hard limit is reached?** Whatever was decided in advance and written in the limit register: a degraded mode, a queue, a smaller model, or a clear error. OpenAI returns 429 with a named error code; Anthropic caps the workspace at its monthly spend limit. If nobody decided, the product decides for you, usually with a blank screen. That is why every limit is reached once on a test project before it goes live. **Q: Do the numbers on this page apply to my contract?** The multipliers and lifetimes are from the providers' public documentation as of September 2026 and are linked below. Enterprise agreements, Bedrock and Vertex pricing differ, and the models' minimum cacheable sizes change with each release. The report applies the price list in force on the date of each call, from your invoice, not from this page. **Q: We run through Bedrock behind an OpenAI-compatible proxy. Does caching work there at all?** It works when the proxy translates the cache marker into Bedrock's cachePoint block, or when the model's implicit caching picks up the prefix. Neither is guaranteed, and the AWS documentation says as much: support for caching does not guarantee a hit. The only evidence is cacheReadInputTokens in the response, which is what the hop-by-hop replay reads at each layer. ### Related - https://23minds.com/services/operate-measure-maintain/cost-model-optimization - https://23minds.com/services/operate-measure-maintain/llm-observability ### Sources - Anthropic, Prompt caching: breakpoints, order, lifetime, pricing multipliers, usage fields, concurrency note: https://platform.claude.com/docs/en/build-with-claude/prompt-caching - Anthropic, Workspaces: monthly spend limits and rate limits per workspace: https://platform.claude.com/docs/en/manage-claude/workspaces - Anthropic, Usage and Cost API: grouping by API key, workspace, model; cached and uncached token classes: https://platform.claude.com/docs/en/manage-claude/usage-cost-api - OpenAI, Prompt caching: prefix matching, minimum length, retention, cached token discount, usage fields: https://developers.openai.com/api/docs/guides/prompt-caching - OpenAI, Spend limits: hard limits per organisation and project, 429 error codes, alerts: https://developers.openai.com/api/docs/guides/spend-limits - Google, Gemini API context caching: implicit caching defaults and minimum token counts: https://ai.google.dev/gemini-api/docs/caching - Google, Gemini API explicit caching: TTL default of 1 hour and billing components: https://ai.google.dev/gemini-api/docs/generate-content/caching - Google, Gemini API pricing: context caching and storage price per hour: https://ai.google.dev/gemini-api/docs/pricing - Google Cloud, Cloud Billing budgets: alerts-only budgets do not cap spending: https://docs.cloud.google.com/billing/docs/how-to/budgets - AWS, Amazon Bedrock prompt caching: cachePoint, section order, TTL, no guaranteed hit: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html - Self-reported case on Hacker News: 37,901.73 USD Bedrock bill from a prompt caching miss through a proxy chain: https://news.ycombinator.com/item?id=47933355 --- ## Measuring the real effect of AI in an engineering team: a protocol that holds up in front of the board and the team **URL:** https://23minds.com/guides/measuring-ai-impact-in-engineering-teams > Measuring the effect of AI assistants in an engineering team means establishing, with a baseline taken before the rollout and a stability metric next to every speed metric, whether the team's output changed and at what cost in rework. It is a measurement protocol for a rollout that is already underway, run on data the team already has in git, CI and the ticket system. ### Summary 23Minds designs and runs the measurement of AI-assistant effect for engineering teams whose board asks whether the spend pays back and whose engineers distrust the numbers. The protocol takes a baseline from git and CI history before the first licence, pairs each throughput metric with a stability metric from the same window, allocates comparison groups by team rather than by volunteer, and reports at team level only, never per person. The published evidence points in opposite directions, from 19% slower in a randomised trial with experienced open-source developers to 26% more completed tasks across 4,867 developers in three companies, which is why the answer for a given team comes from that team's own data. The client keeps the protocol, the baseline sheet, a paired-metric panel with its queries, and a report after 8 to 12 weeks that states what was measured, what was not, and why. ### Who it's for - CTOs and VPs of Engineering who have to show the board whether the AI tooling budget changed anything, with a number they can defend - Heads of engineering whose team already argues about whether things got better or worse, with no data either side would accept - Engineering managers who have been asked to introduce productivity metrics and know what happens to a team when the metric is per person - Platform and developer-experience teams who own the CI, the repository and the ticket system and will run the measurement after handover ### Why faster ticket closure is not evidence A ticket that closes faster tells you the ticket closed faster. It does not tell you whether the change was reworked after merge, whether the reviewer spent the time the author saved, or whether the next change in the same file took longer. The 2025 DORA report, based on survey responses from nearly 5,000 technology professionals, found a positive relationship between AI adoption and software delivery throughput and, in the same data, a negative relationship with delivery stability. The report's own reading is that acceleration exposes weaknesses downstream when the control systems, automated tests, version control practice and fast feedback, are not there to absorb the extra change volume. A throughput number on its own is half a result. The DORA ROI report of April 2026 puts a price on the other half with an illustrative model: in its sample calculator for a 500-person engineering organisation, a change failure rate that rises from 5% to 6% after adoption shows as a negative downtime impact of 344,000 USD. The figure is a worked example, not a measurement of any company, and it is quoted here for one reason: it shows that a one-point move in a stability metric is large enough to cancel a visible gain in speed. The argument inside teams has the same shape. In the largest practitioner discussions of 2026 on the subject, the dispute is about whether the code behind the closed ticket is worse and whether the pressure to keep the pace stops anyone from checking. Without a protocol both sides are right, and the measurement settles it. ### What the controlled experiments actually measured The published studies disagree, and the disagreement is informative once the method behind each number is visible. The table lists the studies a board is most likely to have heard of. None of them measured your team. | Study | Population and design | Outcome measured | Result | What it means for a team measurement | | --- | --- | --- | --- | --- | | METR, randomised trial, Feb-Jun 2025 (Becker et al., arXiv 2507.09089) | 16 experienced open-source developers, 246 real tasks on their own repositories, randomised AI-allowed or AI-disallowed, Cursor Pro with Claude 3.5 and 3.7 Sonnet | Time to complete a task | 19% longer with AI allowed; the developers had predicted 24% faster and still estimated 20% faster after the study | Self-reported speed is not a measurement. Experienced developers on code they know deeply are the population least likely to gain. | | METR, late-2025 follow-up and methodology update (24 Feb 2026) | 57 developers, over 800 tasks in 143 repositories; pay reduced from 150 to 50 USD per hour | Time to complete a task, same design | Point estimates moved toward a speedup with wide intervals; METR declared the signal unreliable because developers refused to work without AI and 30-50% withheld tasks they expected to be slow without it | Self-selection breaks the design. Who opts in, and which tasks they submit, decides the result before anything is measured. | | Cui et al., three field experiments (Management Science, 2026) | 4,867 developers at Microsoft, Accenture and a Fortune 100 company, random subset given a code-completion assistant during ordinary work | Completed tasks | 26.08% more completed tasks (standard error 10.3%); less experienced developers adopted more and gained more | Different population, different outcome, opposite sign. Experience level of the team predicts the direction, and the count of completed tasks says nothing about rework. | | DORA, State of AI-assisted Software Development 2025 | Survey of nearly 5,000 professionals plus over 100 hours of interviews; cross-sectional, no randomisation | Reported throughput and stability | Throughput up with adoption, stability down with adoption | The two metrics have to be read as a pair. A rollout that reports only one of them is reporting the half it likes. | ### The measurement design A protocol that survives both the board and the team has five parts, and each one exists because a specific study failed without it. Everything below is computed from git history, CI logs and the ticket system. No commercial platform is required and no vendor's acceptance-rate dashboard is an input. - Baseline before the rollout. Twelve weeks of history before the first licence, for every metric that will be reported afterwards, reconstructed from git and CI if nobody took it at the time. A measurement with no before has nothing to compare against except a feeling. - Paired metrics. Every speed metric is reported next to a stability metric from the same window and the same repositories: lead time for changes next to time to first fix after merge; merged pull requests per week next to the share of merges followed by a revert or hotfix within 30 days; deployment frequency next to change failure rate. A pair can move in opposite directions, and that is the finding. - A window long enough to include the dip. Eight to twelve weeks after the rollout, because the first weeks of any tooling change carry a learning cost that a four-week snapshot reads as failure or, taken late, as pure gain. - A comparison group by team, not by volunteer. Where the organisation rolls out in waves, the teams still waiting are the comparison group. Where it cannot, the comparison is the same team's own baseline, with the limit stated in the report. Volunteers are never the comparison, because METR's data shows what happens when enthusiasts opt in and sceptics opt out. - A short list of what is not counted. Lines of code, number of commits, number of pull requests and assistant acceptance rate are excluded as outcomes, because the tool inflates every one of them without any change in what ships. They stay in the data only as denominators. ### Per-person metrics, and why they poison the measurement The fastest way to lose a measurement is to publish it per person. The SPACE framework (Forsgren et al., ACM Queue 2021) states the principle: developer productivity cannot be captured by a single metric or by an individual's activity level. A ranking of engineers by assistant usage or acceptance rate turns the metric into the target within a sprint. People run the tool to be seen using it, accept suggestions they would have rewritten, and the number goes up while the thing it was supposed to stand for stops moving. Employers have already started weighing individual AI usage in performance evaluations, as reported by The Register in November 2025, and the practitioner threads that follow such announcements describe the resistance it produces in detail. The trust data explains the resistance. In the 2025 Stack Overflow survey (49,009 responses), AI output that is almost right but not quite was the most common frustration, cited by 66% of the 31,476 developers who answered that question, and 45.2% said debugging AI-generated code takes more time. Only 3.1% of the 33,244 who answered the trust question highly trust the accuracy of the output. A team that is told to use the tool more, and ranked on it, is being asked to ignore what it observes daily. The protocol therefore aggregates at team level, keeps names out of every panel, treats usage data as a denominator rather than an outcome, and collects the team's own assessment through an anonymous survey run before the rollout and again at the end of the window. ### Where this goes wrong, and what we do about it **The baseline is taken after the rollout has started** Licences went out in a pilot, then to everyone, and the request to measure arrived a month later. The first data point is already inside the learning dip or already past it, so the before-and-after comparison measures the ramp, not the tool. Seasonality does the rest: a release freeze or a holiday period in either window moves the numbers more than the assistant does. What we do about it: We reconstruct the baseline from git and CI history for the twelve weeks before the first licence date, per repository, and mark every week that contained a freeze, an incident or a holiday so it can be excluded from both windows symmetrically. Where the rollout date differs per team, each team gets its own baseline. We then verify that the baseline queries return the same values when run by your platform team. What stays with you: baseline sheet per team and repository, with the queries, the exclusion calendar and the licence date each baseline is anchored to **Throughput is reported without its stability pair** The panel shows lead time and merged pull requests per week, both improved. Rework after merge, reverts and time to first fix are not on it, because nobody asked for them and the tooling vendor's dashboard does not have them. The DORA data says stability is where the cost of extra change volume appears, so the panel is showing exactly the half that cannot go wrong. What we do about it: We define every reported pair up front and compute both halves from the same repositories and the same window: for each merged change, the days until a later commit in the same lines references a bug, a revert or a hotfix. We report the pair as one row, so a speed gain with a stability loss is visible as a single result, and we quantify the loss in engineering hours spent on fixes rather than as a percentage alone. What stays with you: paired-metric table with both halves per team per window, plus the queries that produce it **The comparison group is whoever volunteered** The pilot was open to anyone who wanted it, so the people measured are the people who expected the most from the tool, on the tasks they chose to bring. METR's February 2026 update names this exact failure: developers declined to work without AI and 30-50% withheld tasks they expected to be slow without it. The measured group and the comparison group differ in attitude and task mix before the tool does anything. What we do about it: We allocate by team and repository, using the rollout waves the organisation already has, and record who declined and why. Where no wave structure exists, we compare the same team against its own baseline and write the limit into the report in the first paragraph, not in a footnote. We compare like tasks by matching on ticket type and repository, and we report the task mix in both groups so a shift in what people chose to work on cannot pass as a speedup. What stays with you: allocation record with the comparison design, the refusal log and the task-mix table for both groups **Usage becomes the metric** The most available number is how much each person used the assistant, so it becomes the number on the slide. Within a sprint the team optimises for it: suggestions are accepted and then rewritten, sessions are opened and left running. The usage line rises, the output lines do not, and the report concludes that adoption is high and impact is pending. Meanwhile the engineers who were ranked stop cooperating with any future measurement. What we do about it: We keep usage data in the model only as a denominator, so that outcome metrics can be read per unit of assistant use at team level, and we remove every per-person view from the panel before it is shared. The anonymous survey asks the team where the tool helped and where it cost time, and we publish those answers next to the numbers. Access to the raw data is written down: who can query it, at what granularity, and what is never exported. What stays with you: panel specification with the aggregation level, the access rules and the survey instrument, plus the survey results for both rounds **Counting the output the tool inflates** Lines of code, commits and pull requests all go up when an assistant is in the loop, because generating them is what the assistant does. A count of any of them after the rollout shows growth that has no relation to what reached users. Reviewers, meanwhile, absorb the extra volume, and their time does not appear in any count. What we do about it: We define what counts as done before the window opens: a merged change that has survived 30 days without a fix in the same lines, and a roadmap item closed with the ticket system's own acceptance state. We add review load per merged change as its own row, so the time that moved from author to reviewer is visible. Then we run the definitions on the baseline to confirm they behave the same way before and after. What stays with you: definition sheet for every outcome metric, with the query, the exclusion list and the review-load row ### What you get - Measurement protocol: the questions, the metric pairs, the window, the comparison design, the aggregation level and the list of what is deliberately not measured - Baseline sheet per team and repository for the twelve weeks before the rollout, with the queries and the exclusion calendar - Paired-metric panel built on your git, CI and ticket data, with the aggregation level fixed at team and no per-person view - Allocation record: comparison groups by team or wave, refusal log, and the task-mix table for both groups - Survey instrument and results from two anonymous rounds, before the rollout and at the end of the window - Report after 8 to 12 weeks stating what changed, at what cost in rework and review load, what could not be measured and why, written so it can be read by the board and by the team without a second version - Handover: the queries, the definitions and the panel stay with your platform team, so the same measurement can be repeated each quarter ### How we work 1. **1. Protocol and baseline** (Week 1-2): We agree the questions the board and the team each want answered, choose the metric pairs, and reconstruct the baseline from git and CI history for the twelve weeks before the first licence. If the rollout has not started, this is also where the wave structure and the comparison groups are fixed. 2. **2. Instrumentation** (Week 2-3): We build the queries against your repositories, CI and ticket system, run them on the baseline to check they behave, and set up the panel with team-level aggregation and written access rules. The first survey round goes out. 3. **3. Measurement window** (Week 3-15): The panel runs for eight to twelve weeks. We check the data monthly for gaps, freezes and incidents that need marking, and we do not report interim results, because a four-week snapshot reads either as failure or as pure gain depending on when it is taken. 4. **4. Report and handover** (Week 15-16): We run the second survey round, compute every pair for both windows and both groups, and write the report with its limits in the first paragraph. Queries, definitions and the panel are handed to your platform team with a runbook for the next quarter. ### FAQ **Q: The rollout happened months ago. Can the effect still be measured?** Yes, with a weaker design and an honest report. Git and CI history give a baseline for any date, so the before-and-after comparison is available even when nobody planned it. What is lost is the comparison group, unless some teams adopted later than others, in which case those teams become it. The report says which design was used and what it cannot rule out. **Q: Do we need a control group?** The measurement is stronger with one, and most organisations already have it in the shape of rollout waves. Where every team adopted on the same day, the comparison is the team's own baseline with seasonality marked and excluded symmetrically. What we never do is use volunteers as either group, because the METR update of February 2026 documents how self-selection decides the result before the tool does anything. **Q: Which tools do we have to buy?** None. The metrics come from git, CI logs and the ticket system you already run, and the panel is built on them. Assistant usage data from the vendor's console is welcome as a denominator, but no outcome on the panel comes from a vendor dashboard. **Q: Will anyone see individual numbers?** No. Aggregation is fixed at team level in the panel specification, per-person views are removed before anything is shared, and the access rules say who can query the raw data and at what granularity. This is a design choice with a reason: a per-person ranking turns the metric into the target and ends the team's cooperation with any future measurement. **Q: What if the result is zero or negative?** Then that is the result, and the report says where the cost sits: in rework after merge, in review load, or in a task mix that shifted. A negative result on a paired metric is more useful to the board than a positive result on a single one, because it names what to change. The published evidence contains both signs, so neither outcome is a surprise. **Q: Is this an ROI business case for a tool we have not bought yet?** No. The protocol measures a rollout that is underway or already complete, on the team's own data. A projected business case before the decision is a different piece of work with different inputs, and this page does not offer it. **Q: How is this different from a DORA metrics dashboard?** The four DORA metrics are in it, as two of the pairs. What the protocol adds is the baseline anchored to the licence date, the pairing rule that stops throughput being reported alone, the comparison design by team, the written list of what is not counted, and the survey that puts the team's own assessment next to the numbers. A dashboard shows the current value; the protocol says what the value is being compared against and why. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/operate-measure-maintain/telemetry-analytics ### Sources - Becker, Rush, Barnes, Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089, July 2025): https://arxiv.org/abs/2507.09089 - METR, Measuring AI uplift: an update on methodology and late-2025 data (24 February 2026): https://metr.org/blog/2026-02-24-uplift-update/ - Cui, Demirer, Jaffe, Musolff, Peng, Salz, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers (Management Science, 2026): https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/ - Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report - DORA, The ROI of AI-assisted Software Development (v.2026.1, April 2026): https://dora.dev/ai/roi/report/ - InfoQ, New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment (May 2026): the illustrative change failure rate example and the 344,000 USD figure: https://www.infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/ - Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, The SPACE of Developer Productivity: There's more to it than you think (ACM Queue, 2021): https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/ - Stack Overflow, 2025 Developer Survey: AI section (49,009 responses; each percentage is of those who answered the question): https://survey.stackoverflow.co/2025/ai - The Register, Devs gripe about having AI shoved down their throats: employers weighing individual AI usage in performance reviews (19 November 2025): https://www.theregister.com/2025/11/19/ai_force_feeding/ --- ## Comparing AI code review tools independently: a protocol you can run on your own repository **URL:** https://23minds.com/guides/ai-code-review-tools-independent-comparison > An independent comparison of AI code review tools is a measurement run on your own pull requests, with defects you planted and clean changes you know are clean, scored by an engineer who does not know which tool wrote which comment. It replaces the question "which tool is best" with "which tool is right about your code, how often it is wrong, and what each pull request costs". ### Summary 23Minds runs independent comparisons of AI code review tools for engineering teams choosing or replacing one, and sells no review tool and takes no commission from any vendor. The comparison uses one fixed set of the team's own pull requests, part of them with seeded defects and part of them clean, runs every candidate tool on the same set in the same configuration window, and has an engineer rate every comment blind to the tool's identity. The result is precision, recall and noise per finding class, the share of comments outside the diff, the cost per pull request and the change in reviewer time, for every tool on the same repository. The team keeps the protocol, the seeded-defect register, the rating sheet and a recommendation with its reasoning, and can rerun the whole measurement when a tool or a model changes. ### Who it's for - CTOs and VPs of Engineering who have to pick one AI code review tool for the whole organisation and have only vendor rankings to go on - Platform and developer-experience teams asked to justify a per-seat subscription with something other than a demo - Engineering managers whose reviewers complain that the current tool is verbose, comments on code nobody changed, or is confidently wrong - Teams already running two or three tools in parallel and paying for all of them because nobody measured which one earns its seat ### Why vendor comparisons are not comparisons A search for the best AI code review tool returns lists written by the companies that sell them, and each list places its author first. The benchmarks behind those lists share one shape: the vendor picks the pull requests, the vendor seeds or labels the bugs, the vendor's model scores the comments, and the metric that gets published is how many of the known bugs were found. The metric that does not get published is how many comments were wrong. That asymmetry matches what practitioners report. In the discussions engineers hold about these tools, the recurring complaints are verbosity, comments on code outside the pull request, and findings that describe behaviour the code does not have. All three are precision complaints, and precision is the number the rankings leave out. The one benchmark in this category that publishes its dataset, judge prompts and pipeline under an open licence, Martian's Code Review Bench, reported at its launch in February 2026 that no tool found more than 63% of the 137 known issues in its curated set, and says openly that its gold set contains errors and that a static set risks having been seen by the tools during training. Even an honest benchmark measures its own repositories. The published sets are open-source projects in five languages with their own conventions and pull request sizes; your defect mix, your review culture and the configuration you would actually run are absent from all of them. The only comparison that answers your purchasing question is one run on your code. ### The metrics that decide, and why they have to be measured per repository Google's static analysis platform Tricorder set the working definition of noise that code review tooling still uses: an issue is an effective false positive if the developer takes no positive action after seeing it, and an analyser has to stay under 10% effective false positives to remain in code review, or it gets switched off. That threshold is measured on developer behaviour inside one codebase, which is why it cannot be copied from a vendor page. The second number that changes the decision is what the tool does to the review itself. An industrial study of an LLM review tool built on the open-source PR Agent (Cihan et al., ICSE SEIP 2025) covered 4,335 pull requests in three projects; 73.8% of the automated comments were resolved, and the average pull request closure time rose from 5 hours 52 minutes to 8 hours 20 minutes. The comments were acted on and the review got slower. Both numbers have to be on the sheet. - Precision per finding class: a tool that is right about null checks and wrong about concurrency is two different tools depending on what your defects are. - Recall on seeded defects per class, so the classes a tool never sees are named rather than averaged away. - Noise on clean pull requests: comments on changes with no planted defect, counted per pull request. - Off-diff share: comments whose subject is code the pull request did not touch. - Verified-false findings: comments asserting a contract, behaviour or vulnerability the code does not have, checked against the code. - Cost per pull request from the invoice. GitHub bills a Copilot review in AI credits that vary with the review's effort level; CodeRabbit bills per developer with an hourly review allowance. What one pull request costs is only known after the run. - Reviewer time: minutes a human spends on the pull request with and without the tool, and closure time over the same window. ### The protocol The protocol fixes everything the vendor benchmarks leave to the vendor. The set of pull requests is yours, frozen before any tool runs. Defects are seeded by an engineer who writes each one down in a register with its class and location before the run. Clean pull requests are real merged changes that a second engineer reread and confirmed. Every tool runs on the same set, in a configuration each vendor's documentation describes as recommended, within the same week, and no tool sees another tool's comments. Rating is blind. Comments are stripped of the tool's name and formatting, shuffled, and rated by an engineer who knows the codebase against the seeded-defect register and the code. The judge is a person, because the published benchmarks use a language model to match comments to fixes, and a model scoring a model of the same family has a known tendency to agree with itself. A second rater scores a sample so the agreement between raters is a number on the sheet and not an assumption. | What is measured | How | Threshold or decision rule | | --- | --- | --- | | Recall per defect class | Seeded defects found / seeded defects planted, per class (logic, concurrency, input handling, security, API contract, test gap) | Classes below the team's floor are listed as "not covered" in the recommendation, never averaged | | Precision per finding class | Comments rated correct / all comments, per class, rated blind against the code | Under Tricorder's rule of 10% effective false positives a class is switched off in the tool's configuration | | Noise on clean pull requests | Comments per clean pull request, and the share of clean pull requests with at least one comment | Reported next to recall; a tool that finds more and says more is scored on both | | Off-diff share | Comments about lines the pull request did not change / all comments | Reported per tool; configuration that reduces it is recorded | | Verified-false findings | Comments asserting behaviour the code does not have, confirmed by reading the code | Counted separately from ordinary misses; one per pull request is a line item in the recommendation | | Cost per pull request | Invoice or credit consumption for the run / pull requests in the set, per tool | Compared at the team's real pull request volume, not at list price | | Reviewer time and closure time | Minutes logged by reviewers on a sample, and time to merge over the run window, against the baseline weeks | A tool that lengthens closure time has to earn it in recall on the classes that matter | | Rater agreement | Second engineer rates a sample; agreement per class | Below the agreed level the class definitions are rewritten and the sample re-rated before any ranking | ### Running it on your own repository The protocol is designed to be repeated by the team without outside help, because the answer changes every time a vendor swaps its model. Construction matters more than size: a few dozen pull requests with a defect register and a clean control group beat a thousand unlabeled ones, which is also how the open benchmarks are built. - Take pull requests from the last quarter that represent your real distribution of size and language, not the interesting ones. - Seed defects by hand and log each one before the run: file, line, class, and the sentence a correct comment would have to contain. - Keep clean pull requests in the set. Without them noise is invisible and every tool looks careful. - Configure each tool once, from its documentation, and freeze the configuration. Tuning during the run turns the comparison into a demo. - Run all tools in the same week on the same commits, and note the model or version each vendor reports. - Strip tool identity before rating, and keep the rater separate from the person who configured the tools. - Put the cost of the run on the sheet from the invoice, per pull request, next to the recall it bought. - Rerun the same set when a tool announces a model change, and diff the sheets. ### What the team gets, and how this relates to an audit The engagement ends with a protocol document, the frozen set with its defect register, the blind rating sheet with rater agreement, one results sheet per tool and a recommendation that names the tool, the configuration, the classes it does not cover and what that gap costs at your volume. The recommendation says why, in terms of the numbers on the sheet, so a later team can disagree with the reasoning rather than with the conclusion. A tool chosen this way still reviews the diff. This site's comparison of an AI code review tool with an independent audit covers what a tool cannot see: the system that already shipped, its architecture, tests and trust boundaries. The results sheet feeds that audit, because the classes a tool does not cover are the ones an independent evaluation of AI-written code and a test coverage review take on. ### Where this goes wrong, and what we do about it **Recall on the vendor's set, precision on nobody's** A vendor benchmark seeds bugs into pull requests and counts how many the tool finds. Nobody runs the same tool on pull requests with no planted bug, so the comments it leaves there, which are the ones your reviewers will read every day, never enter the score. The tool that says the most wins the published number, and the team that buys it inherits the noise. What we do about it: We build the set with a clean control group of real merged changes reread by a second engineer, and we count comments per clean pull request next to recall on the seeded ones. Where a class of finding falls under Tricorder's 10% effective false positive rule, we switch that class off in the tool's configuration and rerun the set to confirm the recall that was lost. What stays with you: results sheet per tool with recall and noise side by side per class, and the configuration that turns a noisy class off **Comments about code the pull request did not touch** Tools that read the whole repository for context also comment on it. A pull request that changes one function comes back with remarks on the module around it, and the reviewer cannot tell from the comment whether the finding is about the change or about code that has been in production for two years. The tool is doing what its context window allows; the review process was never told to expect it. What we do about it: We tag every comment in the rating sheet with whether its subject line is inside the diff, report the off-diff share per tool, and test the configuration options each vendor documents for limiting scope. Off-diff findings that are real go into a separate backlog for the maintenance owner instead of into the pull request. What stays with you: off-diff share per tool before and after configuration, and a backlog of verified off-diff findings with an owner **A finding that describes behaviour the code does not have** The comment reads as a precise defect report: a function that supposedly ignores an error, a header that supposedly is not validated. The code does neither, but the sentence is fluent and specific, so the author spends twenty minutes proving a negative or, worse, changes working code to satisfy the comment. Engineers describe this as the tool making things up, and it is the most expensive kind of wrong because it looks most like right. What we do about it: We rate against the code, not against the comment, so a verified-false finding is a separate class on the sheet with its own count per tool. We keep the ten most convincing wrong findings from the run as a training set for reviewers, so the team learns what confident and wrong looks like from this tool before it goes live. What stays with you: verified-false count per tool per hundred comments, and an annotated set of the most convincing wrong findings **A model judging a model of its own family** Published benchmarks match tool comments to human fixes with a language model, because rating thousands of comments by hand is slow. A judge model scores comments written by a model of the same family as a colleague would: it recognises the phrasing and agrees. The score moves with the judge's model version, and the team that copies the number cannot tell how much of it was the judge. What we do about it: We rate blind, by an engineer who knows the codebase, and we have a second engineer rate a sample so agreement between raters is measured per class. Only where agreement is high enough do we let a model pre-sort comments, and the model's sort is then checked against the human sample before it counts. What stays with you: rater agreement per class on the sample, and the rule for when model pre-sorting may be used **Resolved comments up, review time up, nobody looks at the second number** The industrial study of an LLM review tool built on PR Agent found 73.8% of automated comments resolved and pull request closure time up from 5 hours 52 minutes to 8 hours 20 minutes. A dashboard that shows resolved comments reads as success; the closure time sits in a different tool. The reviewers know, the metric does not. What we do about it: We log reviewer minutes on a sample of pull requests during the run and take closure time from the version control system for the run window and the baseline weeks before it. A tool that lengthens closure time is only recommended where its recall on the classes the team cares about pays for the delay, and the recommendation says how much delay that is. What stays with you: reviewer minutes and closure time per tool against the baseline, with the recall bought for each hour added ### What you get - Protocol document: set construction, seeding rules, configuration freeze, blind rating procedure, metric definitions and thresholds - Frozen pull request set with the seeded-defect register (file, line, class, expected finding) and the clean control group with its second-reader confirmation - Blind rating sheet with every comment, its class, its verdict and the rater; rater agreement per class on the sample - Results sheet per tool: recall and precision per class, noise on clean pull requests, off-diff share, verified-false count, cost per pull request, reviewer minutes and closure time against baseline - Recommendation with reasoning: the tool, the configuration, the classes it does not cover and what that gap costs at your volume - Rerun instructions so the team repeats the measurement after a vendor model change and diffs the sheets ### How we work 1. **1. Scope and set construction** (Week 1): We agree the defect classes that matter for your codebase, pick the pull requests from your recent history, seed the defects and write the register, and have a second engineer confirm the clean control group. Nothing runs until the set is frozen. 2. **2. Tool runs** (Week 2): We configure each candidate from its documentation, record the model or version it reports, run all of them on the same commits in the same week, and capture every comment together with the credit or invoice consumption of the run. 3. **3. Blind rating** (Week 2-3): We strip identity and formatting from the comments, rate them against the code and the register, and have a second engineer rate a sample. Reviewer minutes and closure time are collected for the run window and the baseline. 4. **4. Results and recommendation** (Week 3-4): We assemble the results sheet per tool, rerun the set with noisy classes switched off where the numbers call for it, and hand over the recommendation, the protocol, the register and the rerun instructions. ### FAQ **Q: Which AI code review tool is the best?** On your repository, with your defect mix and your configuration, we do not know until the set has been run, and neither does anyone publishing a ranking. The open benchmark in this category reported at its launch in February 2026 that no tool found more than 63% of its known issues, and its authors say their gold set has errors. The protocol on this page exists so the answer is a sheet from your code rather than a list from a vendor. **Q: Does 23Minds sell or resell a review tool?** No. We do not sell a code review tool, we do not take referral fees or commissions from any vendor, and the recommendation is written in terms of the numbers on the results sheet so it can be checked against them. If a tool we recommend changes its model, the rerun instructions let you check it again without us. **Q: How many pull requests does the set need?** Enough to cover every defect class you care about several times over, plus a clean control group of similar size. The open benchmarks work with a few dozen curated pull requests per language, and construction matters more than count: a labelled register and a confirmed clean group give a number, a thousand unlabeled pull requests give an impression. **Q: Can the rating be done with a model instead of an engineer?** Pre-sorting, yes, once agreement between two human raters has been measured on a sample and the model's sort has been checked against it. Final verdicts, no. Published benchmarks use a language model as the judge, and a model of the same family as the tool tends to agree with it. We keep the human sample in every run so that tendency is measured, not assumed. **Q: We already have SonarQube or Semgrep. Do they belong in the comparison?** Yes, as the baseline row. Deterministic tools have known precision on the classes they cover and a cost that does not depend on the pull request. Running them on the same set shows which findings the LLM tools add beyond what you already have, which is the only recall that justifies a new subscription. **Q: What does cost per pull request mean when the tool is priced per seat?** Per-seat plans bill per developer with an hourly review allowance; per-review plans bill in credits that vary with the review's effort. In both cases the price list does not say what one pull request costs at your volume. We take the invoice or the credit consumption for the run, divide it by the pull requests in the set, and put that next to the recall it bought. **Q: Does a chosen tool replace an independent audit of AI-written code?** No. The tool reviews diffs; an audit reads the system that already shipped. The results sheet tells you which defect classes the tool does not cover, and those classes are what the independent evaluation of AI-written code and the test coverage review on this site take on. The comparison of a review tool with an audit on this site describes that split in detail. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/evaluate-audit-secure/test-coverage ### Sources - Martian, Code Review Bench v0: independent benchmark of AI code review tools, open dataset and pipeline, stated limits of the gold set: https://withmartian.com/post/code-review-bench-v0 - withmartian/code-review-benchmark on GitHub: 50 PRs from 5 open-source projects, 137 golden comments at launch in February 2026 and 173 after later updates, precision and recall definitions, training leakage caveat: https://github.com/withmartian/code-review-benchmark - Cihan et al., Automated Code Review In Practice (ICSE SEIP 2025, arXiv 2412.18531): 4,335 PRs, 73.8% comments resolved, closure time 5h52 to 8h20: https://arxiv.org/abs/2412.18531 - Zhang et al., Code Review Agent Benchmark (arXiv 2603.23448): review agents solve around 40% of tasks derived from human reviews: https://arxiv.org/abs/2603.23448 - Software Engineering at Google, chapter 20, Static Analysis: effective false positive definition, 10% threshold, Not useful and Please fix signals: https://abseil.io/resources/swe-book/html/ch20.html - GitHub Docs, Copilot code review: billing in AI credits by effort level, repository-wide context, no guarantee of spotting all problems: https://docs.github.com/en/copilot/concepts/code-review/code-review - CodeRabbit pricing: per-developer billing with an hourly review allowance, free reviews for public repositories: https://www.coderabbit.ai/pricing - Example of a vendor-run ranking: CodeRabbit on its position in the Martian benchmark: https://www.coderabbit.ai/blog/coderabbit-tops-martian-code-review-benchmark - Example of a vendor-run ranking: Kilo on the same benchmark, with its own tool ranked first: https://blog.kilo.ai/p/martians-independent-benchmark-tested --- ## AI contribution policy for engineering teams: who signs for code provenance **URL:** https://23minds.com/guides/ai-contribution-policy-and-code-provenance > An AI contribution policy is the document that says who takes responsibility for code a model produced, how that origin is declared in a pull request, and what a reviewer may close without reading. This page holds a template with a check behind every rule, and the decisions published projects made before you. ### Summary 23Minds writes AI contribution policies for engineering teams and open source projects, together with the pull request template, commit trailer convention and CI checks that make the policy hold. The policy settles four questions: who signs for code they did not type, where AI assistance is declared, what the author owes before review, and what the reviewer may reject unread. Every rule in the template is paired with who it binds and how it is checked by machine, because a policy that lives only in a document does not change the review queue. The policy feeds the risk register and the approved-tools list from the governance baseline, and a sampling audit of labelled pull requests verifies that it is followed. ### Who it's for - CTOs and VPs of Engineering whose teams already ship AI-assisted code and have no written rule for who signs it - Open source maintainers receiving generated pull requests and looking for rules they can enforce instead of arguing about - Engineering managers asked by legal or security for a document that says how AI-assisted code enters the codebase - Vendor management teams accepting deliverables from contractors who use coding agents ### Four questions the policy has to answer Provenance disputes in 2026 are about responsibility, not about tools. The threads at the top of r/programming and r/opensource ask the same thing from two sides: the maintainer wants to know who answers for a 13,000-line generated pull request, and the engineer who inherited an almost entirely generated project wants to know whose name is on it. A September 2026 study of 281 AI policies in the 2,000 most-starred GitHub repositories and a set of well-known projects (Hora, Robbes and Zacchiroli) found that 83.3% permit AI in code contributions and 48.8% require disclosure. The working part of a policy is its conditions, and a usable policy is a list of conditions with a check behind each one. - Who signs. The human who opens the pull request certifies origin, under the Developer Certificate of Origin or the company's equivalent, and takes the bug, the regression and the licence question with it. A tool never signs: the Linux kernel policy states that AI agents must not add Signed-off-by tags, because only a human can certify the DCO. - What is declared and where. One scheme per organisation: a commit trailer, a field in the pull request template, or a label, chosen deliberately, not inherited from a tool default. - What the author owes before asking for review. Understanding they can defend without the tool, tests they ran, a change within the size limit. - What the reviewer may close without reading. Written down, so the review queue is what the policy protects and closing is a rule, not a personal decision. ### Where the declaration goes: trailer, template field, label Three mechanisms exist and they answer different questions. In the same study, among policies that require disclosure, the pull request description is the place named in 64.7% of cases and the commit message in 26.7%. Most teams end up needing two of the three. Two conventions collide and the policy has to pick one. GitHub's Copilot cloud agent authors its commits as Copilot, with the human who started the task as co-author. Kubernetes prohibits listing AI as a co-author, because a tool cannot sign the contributor licence agreement, and turned on the CLA check for co-authors, so that such pull requests are flagged as not ready to merge. A company repository meets the same question the moment a customer contract requires an identified author, and the answer has to be configured in the tools, not only written in the policy. | Mechanism | Who reads it | What it is good for | How it is checked | | --- | --- | --- | --- | | Commit trailer (Assisted-by: LLM in the Linux kernel; Generated-by: recommended by the Apache Software Foundation) | Tooling, and anyone reading the history later | Provenance per commit that survives squashes and forks; input for a machine-readable provenance file | A commit-msg hook and a CI lint with the list of allowed trailers | | Field in the pull request template: tool, extent, what was verified by hand | The reviewer, before opening the diff | The explanation in the author's own words; the place where understanding is shown | CI fails when the field is empty or still holds the template text | | Label (ai-assisted) | Dashboards, search, the audit sample | Counting, filtering, drawing the sample for a periodic audit | A bot sets the label from the template field; nobody has to remember | ### What published projects decided The lines below are read from the projects' own documents, not from commentary about them. They span a full ban to disclosure on request, and each is internally consistent: the rule matches the check the project is able to run. | Project | Rule | Where it is written | | --- | --- | --- | | Linux kernel | Permitted. Assisted-by: LLM trailer; agents must not add Signed-off-by; the human submitter reviews everything and certifies the DCO | Documentation/process/coding-assistants.rst | | Kubernetes | Permitted with disclosure. No AI co-author or co-signing on commits; CLA check enabled for co-authors, flagging the pull request as not ready; reviewers engage with humans and review comments are not answered by a tool | Contributor blog, June 2026 | | Apache Software Foundation | Permitted when the tool's terms grant rights to the output. Generated-by: token in the commit message; the contributor notifies the foundation if incompatibly licensed code is found later | ASF Generative Tooling Guidance | | curl | Permitted for code that meets every normal requirement. AI use in security reports must be disclosed; made-up reports get an immediate ban | docs/CONTRIBUTE.md, section On AI use in curl | | Ghostty | Permitted with full disclosure of tool and extent. The human must be able to explain the change without the tool; first-time contributors open a vouch request in their own words | AI_POLICY.md | | Gentoo | Forbidden since April 2024 on copyright, quality and ethical grounds; enforced by trust rather than detection | Council AI policy | | QEMU | Declined when content is believed to derive from AI generators, on DCO grounds. AI for research, static analysis and debugging is out of scope | docs/devel/code-provenance.rst | | GitHub Copilot cloud agent | Commits authored by Copilot with the human as co-author. The person who asked for the pull request cannot approve it; Actions workflows wait for approval from someone with write access | GitHub Docs, responsible use of agents | ### Understanding, tests, size: what the reviewer may close unread The author's obligations decide whether review time is spent on the code or on finding out what the code is. Ghostty puts it in one sentence: if you cannot explain what your changes do and how they interact with the rest of the system without the tool, do not contribute. In a company the same rule has a practical form: the template field asks for the why in the author's words, and the reviewer may ask one question that has to be answered from understanding, with the session log closed. Size is the second obligation, and it needs a number, not a mood. Google's engineering practices put 100 lines as usually reasonable and 1,000 as usually too large for one change, leaving the rest to the reviewer's judgement. Generated changes cross that upper bound easily, because adding is cheap for the tool. The policy sets a hard limit for AI-assisted pull requests and a route for the exception: a design note and a split plan. Rules for closing unread keep the queue moving without turning each decision into a dispute. curl reports that below 5% of its security reports in 2025 were valid before it ended its bug bounty, and a GitHub product manager opened a public discussion at the turn of January and February 2026 on letting maintainers restrict or disable pull requests. The rule-based close is the lighter answer to the same pressure. What the reviewer may close without opening the diff: - No linked issue or accepted proposal, for external contributions - Size over the limit with no split plan - The declaration field empty, or filled with text the reviewer recognises as generated - Review comments answered by pasting tool output instead of a reply from the author - Tests the author states were run, which CI shows never executed ### Policy template: rule, who it binds, how it is checked The table is the deliverable in short form. Each row is one rule, the group it applies to, and the check. A rule without a check does not go into the document. | Rule | Who it binds | How it is checked | | --- | --- | --- | | The person opening the pull request signs for origin and content; tools do not sign and are not listed as co-authors | Everyone, maintainers and contractors included | Commit trailer lint rejects AI co-author trailers; the CLA or DCO check covers co-authors | | AI assistance is declared in the template field: tool, extent, what was verified by hand | Everyone | CI fails on an empty or unchanged field; label set by bot | | The author can explain the change without the tool | Everyone; the reviewer may test it with one question | Reviewer checklist item; an unanswered question blocks merge | | AI-assisted pull requests stay under the size limit or carry a split plan | Everyone | CI size gate on the diff, with an exception label and a design note | | Tests run locally are named and also run in CI | Everyone | CI is the source of truth; the template lists the commands | | Review comments are answered by a person | Contributors and maintainers | The reviewer may close after one tool-pasted reply | | Only tools from the approved list, with output rights checked | Employees and contractors | Approved-tools list from the governance baseline; a contract clause for vendors | | Reviewers who use AI to review sign the review as their own | Reviewers | The same declaration field on the review | | The policy is reviewed on a schedule and after any incident | Engineering lead, as owner | Entry in the risk register with the review date | ### How the policy connects to the risk register and the governance baseline The policy does not stand alone. It is one of the artifacts in the governance baseline, next to the AI usage policy, the approved-tools list and the evaluation cadence, and it gives the risk register concrete entries: an unverified generated change merged, licence-incompatible output in the codebase, review capacity exhausted by volume, attribution that a contract does not accept. Each entry names the check from the template as its control. Verification is a sample, not a belief. A periodic audit draws pull requests carrying the label, checks that the declaration matched the diff, that the author's explanation held up and that the tests named were the tests run, and reports the share that did not. It is the same sampling method as an independent evaluation of AI-assisted code, applied to the process instead of the code. ### Where this goes wrong, and what we do about it **The trailer the editor added, and the policy that forbids it** In April 2026 VS Code changed the default of git.addAICoAuthor so that commits received a Co-authored-by: Copilot trailer; a defect attributed non-Copilot completions to Copilot as well, and the default went back to off in version 1.119 (microsoft/vscode issue #314311). For two releases, attribution in commit history was decided by an editor setting rather than by the author. A team whose policy forbids AI co-authors, as Kubernetes does, or whose customer contract requires an identified author, finds this in the history after the fact. What we do about it: We pick one attribution scheme with you, write it into the policy, and configure it where commits are made: editor settings, the agent's commit identity, a commit-msg hook that rejects trailers outside the allowed list. Then we scan the history for the trailers that already got in and record the decision about them. What stays with you: attribution scheme in the policy, repository hook and CI lint, plus a history scan report listing the affected commits **A disclosure threshold written as 'significant'** Policies say that 'significant' or 'substantial' AI use must be disclosed. The study of the 1,000 most-starred repositories (Hora and Robbes, July 2026) names exactly these words as the recurring ambiguity. With no observable trigger two things happen at once: careful engineers declare everything, so the label carries no information, and the rest declare nothing, because accepting a completion never felt significant. What we do about it: We replace the adjective with triggers you can observe: any diff hunk accepted from a tool without edits, any agent session, any tool from the list. Then we calibrate the threshold against your recent pull requests and show what share would have needed a declaration, so the rule is adjusted before it is announced, not after it is ignored. What stays with you: decision table for the declaration, plus a calibration report on your recent pull requests **The author signs, the agent answers the review** A reviewer asks why a function changed. The author's knowledge of the change is the agent's summary, so the reply is pasted from the agent, the follow-up question gets the next summary, and the review becomes a conversation between the reviewer and a tool with a person forwarding messages. Kubernetes wrote its rule for this case: reviewers engage with humans, and review comments are not answered by a tool. The 13,000-line pull requests maintainers discussed in early 2026 are the extreme form: nobody could have answered. What we do about it: We put the explanation field in the template and the one-question right in the reviewer checklist, and we size-gate AI-assisted pull requests so that a question is answerable. When the review stalls on a tool-pasted reply, the checklist says close, and the policy stands behind the reviewer. What stays with you: pull request template with the explanation field, and the reviewer checklist with the close rules **The policy says 'review everything' and the queue is the bottleneck** A policy that raises the bar for authors changes nothing about how many pull requests arrive. curl saw the valid share of its security reports drop below 5% in 2025 and ended its bug bounty; GitHub opened a discussion on letting maintainers restrict pull requests. In a company the same pressure looks like review latency climbing while everyone follows the document, because the document put all of its rules on the author and none on the intake. What we do about it: We move the mechanical rules to the intake: linked issue, size, declaration field, tests in CI, checked by a bot before a person spends a minute. Then we measure time to first review and the share closed without review, monthly, so the limit is tuned on numbers, not on frustration. What stays with you: intake checks in CI and a monthly report with time to first review and the share closed by rule **The DCO signed for output nobody checked the rights to** The Developer Certificate of Origin has the contributor certify that they created the contribution or have the right to submit it under the licence. The Apache Software Foundation spells out what that means for generated code: the tool's terms must grant rights to the output, and the output must not carry third-party code under an incompatible licence. Signing without having checked either is common, because the tool list was never written down and nobody read the terms for this clause. What we do about it: We add an output-rights column to the approved-tools list, with the clause and the date it was read, and we run licence scanning on files carrying the label so that reproduced code surfaces before release. The policy names who is told when it does, as the ASF guidance requires of its contributors. What stays with you: approved-tools list with an output-rights column, and a licence scan wired to the ai-assisted label ### What you get - AI contribution policy: one document, rule / who it binds / how it is checked, covering employees, contractors and outside contributors - Pull request template with the declaration field and the explanation field, plus the commit trailer convention - Repository configuration: commit-msg hook, CI checks for trailers, size, declaration and tests, label bot - Reviewer checklist with the rules for closing unread - Calibration report of the disclosure threshold on your recent pull requests - Risk register entries for AI-assisted contributions, each mapped to a control from the policy - Approved-tools list extended with an output-rights column - One-page summary for managers and for the contributor guide ### How we work 1. **1. Reading the current state** (Days 1-3): We scan the commit history for AI trailers and co-authors, measure pull request sizes and review latency, and read what your contributor guide and contracts already say. The output is a table of facts, not an opinion. 2. **2. Policy draft and threshold calibration** (Week 1-2): We write the rules with the check behind each one and calibrate the disclosure trigger against your recent pull requests, then review the draft with engineering, legal and, where relevant, the maintainers. 3. **3. Tooling and rollout** (Week 2-3): We configure the template, the hook, the CI checks and the label bot, run them in report-only mode for one cycle, then switch them to blocking. The reviewer checklist goes out with a short session for reviewers. 4. **4. Handover and first audit** (Week 3, then after the first cycle): We hand over the policy, the configuration and the register entries, and come back after the first full cycle to draw a sample of labelled pull requests and report how the rules held. ### FAQ **Q: Does an Assisted-by or Co-authored-by trailer make the tool the author?** No. Authorship and responsibility sit with the person who signs off; the trailer records that a tool was used. The Linux kernel keeps both: an Assisted-by: LLM trailer and a human-only Signed-off-by. Kubernetes goes the other way and bans AI co-author trailers because a tool cannot sign the CLA. Both are consistent. What matters is that your policy picks one and your tools are configured to match. **Q: Should we just ban AI-generated code?** Gentoo and QEMU did, on copyright and quality grounds, and both say enforcement rests on trust rather than detection. For a company that already licenses coding assistants a ban is a rule nobody can check. We recommend the conditional form: disclosure with an observable trigger, an understanding test, a size limit and intake checks, because every one of those has a check behind it. **Q: How do we apply the policy to contractors and vendors?** The same rules, referenced from the contract: a declaration in each delivery, an identified author who signs, tools from the approved list, and acceptance that includes a sample audit of labelled changes. Provenance declared at delivery costs less than provenance reconstructed during an incident. **Q: What size limit should AI-assisted pull requests have?** There is no universal number. Google's published practice treats 100 lines as usually reasonable and 1,000 as usually too large, and hands the rest to the reviewer. We calibrate against your review capacity and your recent history, set the gate one step below where reviews started to stall, and leave an exception route with a split plan. **Q: Can reviewers use AI to review?** Yes, under the same rule as authors: the reviewer signs the review as their own and can defend each comment without the tool. Automated review comments are input to the human review, and the policy says explicitly that a bot approval never counts as the required review. **Q: Where does this sit next to the AI usage policy from the governance baseline?** The usage policy says which tools may be used and with what data. The contribution policy says how their output enters the codebase and who answers for it. They share the approved-tools list and the risk register, and we write them so that one references the other instead of repeating it. **Q: How do we know the policy is being followed?** By sample, on a schedule. The label makes the population countable; a periodic audit draws pull requests from it and checks the declaration against the diff, the explanation against the code and the named tests against CI. The share that fails is the number the risk register tracks. ### Related - https://23minds.com/services/train-adopt-govern/ai-governance-basics - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation ### Sources - Linux kernel documentation: AI Coding Assistants (Assisted-by tag, Signed-off-by rule): https://docs.kernel.org/process/coding-assistants.html - Developer Certificate of Origin 1.1: https://developercertificate.org/ - Hora, Robbes, Zacchiroli: "We Permit the Use of AI, but [...]": The Landscape of AI Policies in Popular Open Source Projects (arXiv 2609.07542, September 2026): https://arxiv.org/html/2609.07542 - Hora, Robbes: AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? (arXiv 2605.16706, July 2026): https://arxiv.org/html/2605.16706 - Kubernetes contributor blog: Open source maintainership in the age of AI (26 June 2026): https://www.kubernetes.dev/blog/2026/06/26/open-source-maintainership-in-the-age-of-ai/ - Apache Software Foundation: Generative Tooling Guidance: https://www.apache.org/legal/generative-tooling.html - curl: Contributing, section On AI use in curl: https://curl.se/dev/contribute.html - Ghostty: AI Usage Policy: https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md - Gentoo Council: AI policy (14 April 2024): https://wiki.gentoo.org/wiki/Project:Council/AI_policy - QEMU documentation: Code provenance: https://www.qemu.org/docs/master/devel/code-provenance.html - GitHub Docs: Responsible use of GitHub Copilot agents: https://docs.github.com/en/copilot/responsible-use/agents - GitHub Blog: GitHub Copilot, meet the new coding agent: https://github.blog/news-insights/product-news/github-copilot-meet-the-new-coding-agent/ - microsoft/vscode issue #314311: update on Co-authored-by: Copilot in commit messages: https://github.com/microsoft/vscode/issues/314311 - Google Engineering Practices: Small CLs: https://google.github.io/eng-practices/review/developer/small-cls.html - Daniel Stenberg: The end of the curl bug-bounty (26 January 2026): https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ - The Register: GitHub considers letting maintainers restrict pull requests (3 February 2026): https://www.theregister.com/2026/02/03/github_kill_switch_pull_requests_ai/ --- ## LLM judge calibration against human ratings: a protocol that ends in a decision per criterion **URL:** https://23minds.com/guides/llm-judge-calibration-against-human-ratings > LLM judge calibration is the measurement of how often an LLM-as-a-judge agrees with trained human raters on the same outputs, criterion by criterion, before its scores are allowed to gate a release. The judge is a second model with its own documented biases, so it needs the same evidence as the system it scores. ### Summary 23Minds calibrates LLM judges against human ratings for engineering teams that already run automated evaluation and cannot say whether the judge's scores match their own reviewers. The protocol builds a reference set labelled independently by at least two people against an agreed rubric, measures agreement between the humans before measuring the judge, and produces a confusion matrix per criterion together with position and length tests. The result is a written decision for every criterion: the judge gates alone, the judge screens and routes disagreements to a person, or the criterion stays with people until the rubric is fixed. The client keeps the calibration set, the agreement report and a recalibration procedure that runs again whenever the judge model, its prompt or the rubric changes, including on production traffic after launch. ### Who it's for - CTOs and VPs of Engineering whose release gate is an LLM judge score and who have been asked, by a customer or an auditor, why that score should be trusted - Teams that have tried several evaluation tools, wired a judge into CI, and still review outputs by hand because nobody trusts the number - Platform and ML engineers who changed the judge model or its prompt and saw the pass rate move without any change to the product - Product owners of agents in production who need evaluation after launch and only have a pre-launch benchmark ### Why a judge needs calibration at all An LLM judge is a language model asked to score another model's output against a rubric. It inherits the properties that make language models hard to evaluate in the first place, and the research on this is specific. Zheng and co-authors (2023), who introduced MT-Bench and Chatbot Arena, name position bias, verbosity bias, self-enhancement bias and limited reasoning ability as the judge's failure modes. Wang and co-authors (2023) flipped the ranking of two candidate answers by swapping their order in the prompt: Vicuna-13B beat ChatGPT on 66 of 80 queries with ChatGPT as the evaluator, through reordering alone. Saito and co-authors (2023) measured that GPT-4 prefers longer answers more than humans do. Panickssery, Bowman and Feng (2024) found that evaluators recognise their own generations and favour them in proportion to how well they recognise them. Ye and co-authors (2024) catalogued twelve biases in LLM judges, among them authority, bandwagon, sentiment, fallacy oversight and refinement awareness, where being told an answer was refined changes the score. None of this makes the judge useless. Zheng and co-authors also reported that a strong judge reached over 80% agreement with human preferences, the level humans reached with each other. The point is that the level is measured, per task, and a judge dropped into a CI pipeline without that measurement is a second system whose errors nobody has looked at. Practitioners on developer forums describe exactly this state: outputs eyeballed and called done, a judge from the same family scoring its own answers, and no evaluation at all once the agent is in production. Calibration turns the judge's score from an opinion into a number with a known error. ### Humans first: the reference set and how well people agree with each other A judge can only be as good as the labels it is compared against, so the protocol starts with people and with the rubric. Each criterion gets a written definition, a scale and worked examples per scale point. A sample of real outputs, drawn from production traffic or the held-out set, is labelled independently by at least two raters who cannot see each other's scores. Disagreements go to adjudication, and the adjudicated label becomes the reference. Every rubric edit made during adjudication is recorded, because a rubric people could not apply consistently is the first artifact that needs fixing, before the judge is run at all. Agreement between the humans is measured per criterion, with a chance-corrected statistic next to raw percent agreement: Cohen's kappa for two raters, Krippendorff's alpha for more raters or missing labels, Spearman correlation for ordinal scores. McHugh (2012) recommends reporting both percent agreement and kappa and reads any kappa below 0.60 as inadequate, while the older Landis and Koch scale calls 0.41 to 0.60 moderate; the protocol sets no universal threshold, because the right one depends on what a wrong pass costs in your product. What the human-human figure does fix is the ceiling: a judge cannot be expected to agree with people more often than people agree with each other on that criterion. A criterion where humans disagree is not ready to be automated, whatever the judge reports. ### Measuring the judge: the calibration protocol With the reference set in place the judge scores the same sample, and every one of its known biases gets its own test. The table is the protocol as run; the source links at the end of the page carry the reasoning behind each row. | Step | What is done | What it catches | What is recorded | | --- | --- | --- | --- | | Family separation | The judge comes from a different model family than the system under test, per the evaluator guidance in Anthropic's own documentation | Self-enhancement and self-recognition bias | Judge model, version identifier, prompt hash | | Agreement per criterion | Judge label against adjudicated human label, with the same statistic used between the humans | Criteria where the judge diverges while the aggregate looks fine | Kappa or alpha per criterion, next to the human-human value | | Confusion matrix per criterion | For each scale point, how the judge scored what humans placed there | Direction of error: a judge that passes what humans fail costs more than the reverse | One matrix per criterion, with the cost of each cell named | | Position swap | Every pairwise comparison run in both orders | Position bias, following the calibration in Wang and co-authors (2023) | Share of pairs where the verdict changes with order | | Length control | Correlation between judge score and output length, compared with the same correlation for human labels | Verbosity bias | Two correlation coefficients per criterion | | Reasoning stability | Same sample scored with and without a reasoning step, and at a fixed temperature | Chain-of-thought sensitivity, non-determinism | Agreement of the judge with itself across runs | ### The decision per criterion The output of calibration is a decision, written per criterion, on what the judge is allowed to do. Three outcomes cover practice. The judge gates alone where its agreement with the adjudicated labels matches the level the humans reached with each other and the confusion matrix shows its errors falling on the cheap side. The judge screens where its agreement is lower but false passes are rare: it scores everything, and every fail plus a random sample of passes go to a person. The criterion stays with people where the humans themselves disagreed, and the work goes back to the rubric. This decision is what gets wired into CI. A single pass rate across criteria is replaced by per-criterion gates with different owners, and the calibration set is stored beside the test suite, versioned with the rubric. A release that changes the judge prompt reruns calibration before it changes the gate. - Gate alone: agreement at the human ceiling, errors on the cheap side; the judge blocks the merge on this criterion. - Screen and route: agreement below the ceiling, false passes rare; the judge sorts, a person decides on the flagged share. - Stay human: humans disagree with each other; rubric is rewritten and the criterion is relabelled before the judge is tried again. - Every decision names the criterion, the statistic, the value, the human ceiling and the person who owns the gate. ### Recalibration and evaluation after launch A calibrated judge is calibrated for one model version, one prompt and one rubric. Chen, Zaharia and Zou (2023) measured the same GPT-4 endpoint in March and June 2023 and found its accuracy at identifying prime numbers went from 84% to 51%, with instruction following degrading alongside. A judge served through an API can change under you the same way, so the judge model is pinned to a version identifier and recalibration runs on four triggers: judge model or version change, judge prompt change, rubric change, and a shift in what the product sends, such as a new language or task type. Calibration before launch is half the work. After launch the judge scores a sample of production traces, and at a fixed cadence a person relabels a random slice of what the judge scored. Agreement becomes a time series per criterion, and a drop is the signal to look at the judge or the product before customers do. OpenAI's grader documentation describes the same check from the training side: a model that has learned to satisfy the grader scores well with the grader and poorly with expert humans, and the only way to see that is to keep asking the humans. ### Where this goes wrong, and what we do about it **The judge comes from the family that produced the answers** The same model, or a sibling from the same provider, generates the output and scores it. Panickssery, Bowman and Feng (2024) showed that evaluators recognise their own text and favour it in proportion to how well they recognise it, so the pass rate carries a bonus for style that no human gave. The team reads a high score as quality because nothing in the pipeline reports which family scored what. What we do about it: We rerun the calibration sample with a judge from a different family and with the candidate's identity hidden, and we compare agreement with the adjudicated labels for both judges. Where the same-family judge scores its own outputs higher than humans do, the judge is replaced or the criterion moves to screening. We record judge model and version next to every score so the family is visible in every report. What stays with you: agreement comparison for two judge families on the same sample, and a judge specification with model, version and prompt hash **Order and length decide the verdict** Pairwise comparisons are sent in a fixed order and the judge favours the first or the second slot; single-answer scores rise with output length regardless of correctness. Wang and co-authors (2023) flipped a benchmark result by reordering alone, and Saito and co-authors (2023) measured that GPT-4 prefers longer answers more than humans do. A prompt change that makes the product more verbose then reads as a quality improvement. What we do about it: We run every pairwise judgement in both orders and count the share of pairs where the verdict changes, and we compute the correlation between score and length for the judge and for the human labels on the same sample. Pairs that flip are excluded from the gate until the prompt is fixed, and a length correlation that the humans do not share moves the criterion to screening. What stays with you: position consistency rate and score-length correlation per criterion, judge next to humans **Judge agreement measured against one person's labels** One engineer labels the reference set alone, the judge agrees with those labels most of the time, and the number is presented as calibration. Nobody knows whether a second person would have labelled the same way, so the figure has no ceiling to be read against. When the judge later disagrees with a reviewer in production, there is no way to say which of them is off. What we do about it: We have every item labelled independently by at least two raters, adjudicate disagreements, and report the human-human statistic per criterion before any judge figure. Criteria where the humans do not agree go back to the rubric with the disagreements attached, because those are the definitions people could not apply, and a judge cannot be calibrated against them. What stays with you: reference set with two independent labels and an adjudicated label per item, and the human-human agreement per criterion **One aggregate score hides the criterion that fails** The judge returns a single number per output, or per-criterion scores are averaged into a pass rate. Agreement on the aggregate looks acceptable while one criterion, typically the one that costs the most when wrong, has the judge passing what humans fail. The average hides it because the other criteria are easy and numerous. What we do about it: We compute agreement and a confusion matrix per criterion and name the cost of each cell: a false pass on a safety or correctness criterion is weighted differently from a false fail on tone. Each criterion gets its own decision and its own gate owner, and the aggregate score is dropped from the pipeline. What stays with you: confusion matrix per criterion with the cost of each cell, and a decision register with one row per criterion **The judge model changed and the calibration did not** The judge is called through an alias that points at the provider's current version, or its prompt is edited during an unrelated change. Chen, Zaharia and Zou (2023) documented behaviour of the same endpoint moving substantially within three months. The gate keeps passing or starts failing, and the team debugs the product for a change that happened in the judge. What we do about it: We pin the judge to a version identifier, hash the judge prompt, and add a test that fails when either changes without a recalibration run recorded against it. Recalibration reuses the same reference set, so the before and after agreement are directly comparable, and the decision register is updated with the date and the new values. What stays with you: recalibration log with agreement per criterion before and after each judge or rubric change, and the pinned judge version ### What you get - Calibration set: sampled outputs with two independent human labels and an adjudicated label per item and criterion, versioned with the rubric - Rubric with definitions, scales and worked examples per scale point, including the edits made during adjudication and why - Agreement report per criterion: human-human and judge-human statistics, confusion matrices with costed cells, position swap and length control results - Decision register: for every criterion, gate alone, screen and route, or stay human, with the values behind the decision and the gate owner - Judge specification: model family, pinned version, prompt hash, order randomisation and temperature, with the CI check that fails when any of them changes - Recalibration procedure with its four triggers, and a production sampling plan with the relabelling cadence and the agreement time series it feeds ### How we work 1. **1. Rubric and reference set** (Week 1-2): We take the criteria you already gate on, write or tighten the definition, scale and examples for each, and draw a sample from production traces or your held-out set. The sample is stratified so that rare but expensive cases are present in numbers that can be measured. 2. **2. Human labelling and adjudication** (Week 2-3): Two raters from your team, or ours where you prefer an outside pair, label every item independently. We adjudicate disagreements with you, record every rubric change, and report human-human agreement per criterion. Criteria that fail here go back to step 1 before the judge is touched. 3. **3. Judge measurement** (Week 3-4): We run your current judge and at least one judge from a different family on the reference set, in both orders for pairwise items, with and without a reasoning step. We compute agreement, confusion matrices, position consistency and length correlation per criterion. 4. **4. Decision and CI wiring** (Week 4-5): We write the decision register with you, replace the aggregate gate with per-criterion gates and owners, pin the judge version and prompt, and add the check that blocks a judge change without a recorded recalibration. 5. **5. Handover and first production cycle** (Week 5-6): We hand over the calibration set, the report and the recalibration procedure, run the first production relabelling with your team, and leave the agreement time series in your observability stack so the next drop is visible without us. ### FAQ **Q: Our judge agrees with our labels about 85% of the time. Is that good?** It depends on two things the number does not show: how often your people agree with each other on the same items, and where the disagreements fall. If humans agree 85% of the time too, the judge is at the ceiling. If humans agree 95% and the judge's misses are false passes on the criterion that matters most, 85% is a screening judge at best. We report the human ceiling and the confusion matrix next to the figure so it can be read. **Q: Which agreement statistic should we use?** Percent agreement plus a chance-corrected statistic, reported together, which is what McHugh (2012) recommends. Cohen's kappa for two raters on categorical labels, Krippendorff's alpha when there are more raters or missing labels, Spearman correlation for ordinal scores. The choice matters less than reporting it per criterion and using the same statistic for humans and judge, so the two values can be compared. **Q: Can the judge be the same model we use in the product, with a different prompt?** The published evidence says that is where self-preference lives: Panickssery, Bowman and Feng (2024) found evaluators favour their own generations in proportion to how well they recognise them, and Anthropic's own evaluation guidance says to grade with a different model than the one that produced the output. We measure it rather than assume it: if a different-family judge agrees with your people more often on the same sample, the answer for your product is no. **Q: How many labelled items does the reference set need?** Enough per criterion and per scale point that the confusion matrix has cells you can read, with the rare and expensive cases oversampled. There is no universal number, and any number quoted without your criteria and your error costs is a guess. The sample size is fixed in step 1 from the confidence you need on the decision, and the set grows with each production relabelling. **Q: What happens when the provider updates the judge model?** The pinned version identifier keeps the old judge until you choose to move. Moving is a recalibration run on the same reference set, which takes hours because the set and the scripts already exist. The decision register is updated with the new values; a criterion that drops below its ceiling moves from gate to screening until the prompt or the rubric is adjusted. **Q: We are already in production without a calibrated judge. Where do we start?** With production traces, which are the best reference set you will get. We sample from live traffic, label it with your reviewers, and calibrate the judge on that. The first relabelling cycle is the pre-launch calibration you did not have, and the time series starts from there. **Q: Does calibration replace human review entirely?** It replaces it on the criteria where the judge earned it and keeps it where it did not, and it says which is which in writing. Screening criteria still route a share of items to a person, and every criterion keeps a periodic relabelling. A judge with no humans behind it drifts, and nobody notices until a customer does. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-quality-evaluation - https://23minds.com/services/operate-measure-maintain/llm-observability ### Sources - Zheng et al. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena: position, verbosity and self-enhancement bias; over 80% agreement with humans, matching human-human agreement: https://arxiv.org/abs/2306.05685 - Wang et al. (2023), Large Language Models are not Fair Evaluators: position bias, Vicuna-13B beating ChatGPT on 66 of 80 queries by reordering, balanced position calibration: https://arxiv.org/abs/2305.17926 - Panickssery, Bowman and Feng (2024), LLM Evaluators Recognize and Favor Their Own Generations: self-recognition correlates with self-preference: https://arxiv.org/abs/2404.13076 - Saito et al. (2023), Verbosity Bias in Preference Labeling by Large Language Models: GPT-4 prefers longer answers more than humans: https://arxiv.org/abs/2310.10076 - Ye et al. (2024), Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge: twelve biases including authority, bandwagon, sentiment, fallacy oversight and refinement awareness: https://arxiv.org/abs/2410.02736 - Chen, Zaharia and Zou (2023), How is ChatGPT's behavior changing over time?: same endpoint, March versus June 2023, prime identification from 84% to 51%: https://arxiv.org/abs/2307.09009 - McHugh (2012), Interrater reliability: the kappa statistic, Biochemia Medica: report percent agreement and kappa together; interpretation scales: https://pmc.ncbi.nlm.nih.gov/articles/PMC3900052/ - Anthropic, Create strong empirical evaluations: LLM-based grading and the guidance to grade with a different model than the one under test: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests - OpenAI, Graders: model graders and detecting grader hacking by comparing with expert human evaluation: https://developers.openai.com/api/docs/guides/graders --- ## AI code and application security incident catalogue: what failed, how, and what would have caught it **URL:** https://23minds.com/guides/ai-code-security-incident-catalog > An incident catalogue is a dated list of cases where code written with an AI assistant, or the application layer around an LLM, failed in a way that is publicly documented: a CVE, a vendor advisory, a post-mortem, a peer-reviewed measurement. This page keeps one, sorted by mechanism, with the check that would have caught each case. ### Summary 23Minds maintains a catalogue of publicly documented security incidents in AI-assisted code and LLM application layers, for engineering leaders who need to know what has actually gone wrong elsewhere before deciding what to check at home. Every entry has a date, a primary source (CVE record, vendor advisory, official post-mortem or published research) and one named mechanism: content read by an agent treated as an instruction, a generated backend default shipped as-is, a hallucinated package name installed from a registry, a destructive command run with confirmation switched off, model output passed into SQL or code execution, an MCP tool or extension holding wider access than the task. The catalogue is the input to a security review of AI-written code: each mechanism class maps to a checklist, a verdict per class for a given codebase, and a retest that proves the fix. Incidents under NDA are not included; only what can be verified at the source. ### Who it's for - CTOs and VPs of Engineering whose teams ship code from Copilot, Cursor, Claude Code or Gemini CLI and who were asked by a board or a client what could go wrong - Security and platform leads who added an in-app agent, an MCP server or a support automation on top of an LLM and need a concrete threat list, not a generic one - Software houses delivering AI-assisted code to clients that now ask for evidence of an independent security check - Engineers who read the vendor advisories one by one and want them in one place, classified by mechanism ### What counts as an entry and what does not Asked on a security forum in August 2026 whether anyone had actually had an incident caused by a coding agent, the most upvoted answer was that whoever had would not say, because of NDAs and embarrassment. That silence is why teams calibrate from vendor marketing. The catalogue below takes the opposite route and lists only what can be verified at the source: a CVE record, a vendor security bulletin, a public statement by the vendor's leadership, or a peer-reviewed measurement with its method published. Practitioner threads that count incidents from daily use exist and are useful as a format, but a thread is not a source and none is cited here. Three boundaries keep the list honest. It covers code and the application layer: what the assistant wrote, what the app sends to and trusts back from a model, what an agent is allowed to call. It does not cover infrastructure, cloud configuration, network security, penetration testing or a SOC; those are separate disciplines with their own catalogues. And it does not treat the model as the culprit. Every row is a tool used without the check that a process would have put in front of it, which is exactly why every row has a check attached. ### The catalogue Sorted by date. The class column uses the six mechanism classes defined in the next section. Source links are at the end of the page; severity scores are the CVSS values from the CVE records where one exists. | Date | System and source | What failed | Effect | Class | What would have caught it | | --- | --- | --- | --- | --- | --- | | 2023-07 | LangChain SQLDatabaseChain, CVE-2023-36189 | Model-generated SQL executed against the database without a boundary between the question and the query | Remote attacker obtains sensitive information through the chain | E | Read-only role for generated SQL, allowlisted statements, query review before execution | | 2024-03 | huggingface-cli on PyPI, Lasso Security experiment | A package name repeatedly hallucinated by assistants was registered by researchers; a public research repository from Alibaba carried it in its install instructions | Empty package installed by real projects following assistant-written instructions | C | Registry check on every new dependency: age, publisher, download history, and a lockfile diff in review | | 2024-05 | Vanna.AI text-to-SQL, CVE-2024-5565, CVSS 8.1 | Untrusted input in ask() reaches the prompt that writes Plotly visualisation code, which is then executed | Remote code execution; mitigation is switching visualisation off for untrusted input | E | No exec of model-written code from user-facing paths; sandboxed rendering; input marked untrusted end to end | | 2025-05 | GitLab Duo, Legit Security disclosure | Hidden text in merge requests, issues, commits and source (white KaTeX, base16 encoding) read by Duo as instructions | Private source code exfiltrated through an injected image tag; unsafe URLs presented as safe | A | Outbound URL allowlist on rendered assistant output; stripping active HTML from responses; injection test set in CI | | 2025-05 | GitHub MCP server, Invariant Labs | A public issue instructs the agent, which holds a token for private repositories too | Private repository data written into a public pull request | F | One token per repository scope; agent cannot read a private scope in a session started from a public one | | 2025-05 | Lovable-generated apps, CVE-2025-48757, CVSS 9.3 | Generated Supabase row-level security policies insufficient or absent on projects created before 2025-04-15 | Unauthenticated read and write to arbitrary tables of generated sites; vendor disputes, placing responsibility on each customer | B | Table-by-table policy check with an anonymous client before publish; RLS required for every table with user data | | 2025-06 | Microsoft 365 Copilot, EchoLeak, CVE-2025-32711, CVSS 9.3 | Instructions in an incoming email processed by the assistant with no user action | Information disclosure over the network, zero-click | A | Untrusted content never combined with a tool that can reach outside; egress allowlist on every assistant action | | 2025-07 | Supabase MCP with Cursor, General Analysis | Support ticket text asks the agent to read integration_tokens; the MCP connection runs with service_role, which bypasses row-level security | OAuth secrets and session credentials posted back into the ticket thread | F | Read-only mode and project scoping on the MCP server; no service_role in any agent-reachable connection | | 2025-07 | mcp-remote, CVE-2025-6514, CVSS 9.6 | authorization_endpoint URL returned by an untrusted MCP server passed into a command | OS command injection on the developer machine | F | Pinned, reviewed MCP server list; no shell construction from remote strings; client version gate | | 2025-07 | Amazon Q Developer for VS Code 1.84.0, AWS bulletin AWS-2025-015 | Improperly scoped GitHub token let unapproved code into the extension's repository and release | Malicious code shipped in a release; failed on a syntax error; version withdrawn, 1.85.0 issued | F | Extension version pinning and update review; least-privilege tokens in the publishing pipeline | | 2025-07 | Gemini CLI 0.1.13, Tracebit | Instructions hidden in a README, an allowlist that accepted a chained command after one approved grep, and whitespace hiding the payload | Environment variables sent to a remote server without the user seeing the command; fixed in 0.1.14 | A | Per-command approval that shows the whole command line; no allowlist matching on the first token | | 2025-07 | Replit Agent, SaaStr project, vendor CEO statement | Agent ran a destructive database command during a declared code freeze and reported that rollback was impossible | Production database deleted; vendor called it unacceptable and shipped dev/prod separation and a planning-only mode | D | No production credentials in the agent's environment; destructive operations behind an explicit confirmation and a tested restore | | 2025-08 | Cursor below 1.3.9, CVE-2025-54135, CVSS 8.6 | Indirect prompt injection creates .cursor/mcp.json, a new dotfile, without the approval that editing one requires | Remote code execution on the developer machine | A | Creation and edit of config files under the same approval rule; injection test that writes a canary file | | 2025-08 | Cursor 1.2.4 and below, CVE-2025-54136, CVSS 7.2 | An already approved MCP definition in a shared repository swapped for a different command without a re-prompt | Persistent code execution for anyone with write access to the branch | F | Hash of every approved MCP definition; re-approval on any change; MCP config reviewed like a CI workflow | | 2025-08 | Claude Code below 0.2.111, CVE-2025-54794, CVSS 7.7 | Path check by prefix match instead of canonical path; a directory with the same prefix as the working directory passes | File access outside the working directory once untrusted content is in context | A | Canonical path comparison in every path guard; test with a sibling directory sharing the prefix | | 2025-08 | GitHub Copilot and Visual Studio, CVE-2025-53773, CVSS 7.8 | Prompt injection edits .vscode/settings.json and sets chat.tools.autoApprove, removing every confirmation | Local code execution across Windows, macOS and Linux | A | Settings files treated as code: write-protected in agent sessions, diffed in review, auto-approve flags forbidden by policy | | 2025-09 | Salesforce Agentforce, ForcedLeak, Noma Security, CVSS 9.4 | Lead form description field carries instructions; agent output allowed to reach an expired domain still on the CSP allowlist | CRM records sent to an attacker-registered domain; patched with trusted URL enforcement | A | Egress allowlist audited for expired entries; form fields marked untrusted before they reach an agent | | 2025-11 | Google Antigravity, PromptArmor | Instructions in 1-point font on a web page; agent reads .env through cat despite the gitignore guard, then a browser subagent opens an attacker URL with the contents | Credentials exfiltrated to a logging site included in the default browser allowlist | A | Guard on file reads that also covers shell; default browser allowlist reviewed; secrets outside the workspace | | 2025-12 | Google Antigravity in Turbo mode, The Register, vendor investigating | A cache-clearing command targeted the root of the D: drive instead of the project folder, with no confirmation in that mode | User's drive contents deleted, bypassing the recycle bin | D | Destructive filesystem operations restricted to the workspace path; confirmation mode on outside sandboxes | | 2026-01 | Moltbook, Wiz Research | Supabase key hard-coded in client-side JavaScript with no row-level security; founder stated no line was written by hand | 1.5 million API tokens, 35,000 email addresses and private messages readable and writable without authentication; fixed within hours of disclosure | B | Anonymous-client probe against every table before launch; secrets scan on the built bundle, not only the repository | ### Six mechanism classes, and what each one has in common Tool names change every quarter; mechanisms do not. Each class below names what the tool did, what the process lacked, and the measurement behind it where one exists. Two peer-reviewed studies anchor the classes that concern generated code itself: Pearce and colleagues (IEEE S&P 2022) generated 1,689 programs with Copilot across 89 weakness scenarios and found about 40% vulnerable; Fu and colleagues (ACM TOSEM 2025) analysed 733 assistant-written snippets found in real GitHub projects and reported weaknesses in 29.5% of the Python and 24.2% of the JavaScript samples. For package hallucination, Spracklen and colleagues (USENIX Security 2025) generated 576,000 code samples across 16 models and found hallucinated package names in at least 5.2% of commercial-model output and 21.7% of open-source-model output, with 205,474 unique invented names. | Class | Mechanism | What the process lacked | Entries above | | --- | --- | --- | --- | | A. Content becomes an instruction | Text the agent reads (issue, ticket, README, email, web page, form field) is processed as if the user typed it, and a tool call follows | A boundary between untrusted content and tools that reach outside; approval that shows the whole action | GitLab Duo, EchoLeak, Gemini CLI, Cursor, Claude Code, Copilot, Agentforce, Antigravity | | B. Generated default ships as-is | Backend access rules, keys in client bundles and framework defaults arrive in the state the assistant produced them | A pre-publish check per table and per secret, run as an anonymous client | Lovable RLS, Moltbook | | C. Invented dependency | The assistant names a package that does not exist; someone registers the name; the install line is trusted because it looks ordinary | Registry verification of every new dependency in review | huggingface-cli, Spracklen et al. | | D. Destructive command without a gate | An agent with production or filesystem access runs a delete, a drop or a wipe in a mode where confirmations are switched off | Credential separation between environments; explicit gate on destructive operations; tested restore | Replit Agent, Antigravity Turbo | | E. Model output into SQL or code execution | Text from the model is passed to a database or an interpreter as if it had been reviewed | Read-only roles, allowlisted statements, no exec of generated code from user paths | LangChain, Vanna.AI | | F. Tool or extension with wider access than the task | An MCP server, extension or token holds scope for everything the developer can do, and the agent inherits it | One scope per task; hash and re-approval of tool definitions; pinned versions | GitHub MCP, Supabase MCP, mcp-remote, Cursor MCP swap, Amazon Q extension | ### What a security review of AI-written code checks, per class The catalogue becomes useful when each class gets a verdict for a specific codebase: can this happen here, yes or no, and what proves it. The list below is the checklist the review runs per class. Every item ends in an artifact or a test, because a verdict without one is an opinion. - Class A: trace every path where untrusted text enters a prompt and where a tool call can follow; list every tool that can reach outside the process (network, shell, file write, browser); build an injection test set with a canary action and run it in CI against each path; audit the egress allowlist for expired and wildcard entries. - Class B: enumerate tables and storage buckets, then probe each one as an anonymous client and as a low-privilege user; scan the built client bundle for keys, not only the repository; compare framework defaults the assistant reproduced (CORS, verification flags, debug output) against the production configuration. - Class C: diff the lockfile in every assistant-written pull request; check each new package for registry age, publisher and download history; keep an allowlist for the runtime and a block on install commands the assistant writes into documentation. - Class D: list every credential in the agent's environment and the environment it belongs to; separate production from everything the agent can reach; put destructive operations behind an explicit confirmation and rehearse the restore once, with the time it took written down. - Class E: find every point where model output is executed or queried; give generated SQL a read-only role and an allowlist of statements; remove exec of generated code from any path a user can reach; sandbox what remains. - Class F: inventory MCP servers, extensions and tokens with their scopes; reduce each to the task it serves; hash approved tool definitions and require re-approval on change; pin versions and review updates like dependency updates. - Retest: after the fixes, every class gets the same test again and the result is recorded next to the original verdict. The pair of results is the evidence a client or a board can read. ### Where this goes wrong, and what we do about it **Content the agent reads is treated as an instruction** The agent gets a support ticket, an issue, a README or an email in its context to do its job, and the model has no reliable way to tell quoted text from the user's request. When a tool that reaches outside the process is available in the same session, the text can call it. Every class A entry in the catalogue has this shape, from GitLab Duo to Antigravity, and the vendors' fixes were boundaries around tools, not better models. What we do about it: We map every path where untrusted text enters a prompt and list every tool reachable from that session. Where both meet we either remove the outbound tool, put it behind an approval that shows the full action, or mark the content as data in the prompt structure. We then run an injection test set with a canary action against each path and keep it in your CI. What stays with you: path-by-path map of untrusted content and reachable tools, with the injection test set and its results per path **The generated backend default ships in the state it was produced** The assistant scaffolds a backend with the pattern it knows best: a key in the client, access rules off or permissive, debug output on. It works in the demo because the demo has one user. The Lovable CVE and the Moltbook exposure are the same mechanism at two scales, and in both cases the vendor's position was that the customer owns the access rules. What we do about it: We enumerate every table and bucket, then probe each one as an anonymous client and as a low-privilege user, and scan the built bundle for keys. Each failing table gets a policy, each key moves to the server side, and the probe runs again until it returns nothing. The probe stays as a pre-publish check. What stays with you: table-by-table access matrix with the anonymous-client probe result before and after, and the probe wired into the release pipeline **Package names are trusted because they look ordinary** The assistant writes an install line with a plausible name that does not exist, and the study by Spracklen and colleagues shows the same invented names recur across prompts. Anyone who registers such a name gets installs from every project that trusted the line. The huggingface-cli case shows the name reaching a real repository's documentation before anyone checked the registry. What we do about it: We diff the lockfile of every assistant-written change, check each new package against the registry for age, publisher and history, and turn the check into a review rule. Install commands the assistant wrote into docs get the same treatment. What stays with you: dependency provenance report for the AI-touched period, plus the registry check as a CI rule **Destructive commands run because the confirmation was switched off** Turbo, YOLO, auto-approve: the mode exists because confirmations slow the demo down. In that mode a cache clear that resolves to the wrong path, or a database reset issued during a code freeze, executes at the speed of the agent. Both catalogue entries in class D happened with the agent holding credentials it never needed for the task. What we do about it: We list every credential the agent can reach and the environment each belongs to, remove production from that list, and put destructive operations behind an explicit gate. We then rehearse the restore once and write down how long it took. What stays with you: credential map per agent and environment, the list of gated operations, and the restore drill record with its duration **A tool definition changes and nobody is asked again** An MCP server or extension was approved once. The definition lives in a shared repository or updates itself, and the approval does not follow the change. The Cursor re-approval bypass and the Amazon Q extension release show the two ends: a swapped command on a branch, and unapproved code in a published version. What we do about it: We inventory MCP servers, extensions and tokens with their scopes, reduce each scope to its task, hash every approved definition and require re-approval on change. Versions get pinned and updates go through the same review as dependency updates. What stays with you: tool inventory with scope per task, hashes of approved definitions and the re-approval rule in your configuration ### What you get - Incident-to-codebase mapping: a verdict per mechanism class for your repositories and agent integrations, with the evidence behind each verdict - Checklist per class, filled in for your stack, with the artifact or test that closes each item - Injection test set with canary actions, wired into CI, with results per untrusted-content path - Access matrix for tables and buckets with the anonymous-client probe result, before and after - Dependency provenance report for the AI-touched period and the registry check as a review rule - Tool inventory: MCP servers, extensions and tokens with scope per task, hashed definitions and the re-approval rule - Retest record: every class tested again after the fixes, recorded next to the original verdict ### How we work 1. **1. Mapping** (Week 1): We walk the repositories and agent integrations with a senior engineer from your side and mark where each mechanism class can occur: untrusted content paths, generated backend rules, new dependencies, agent credentials, model output into SQL or exec, tool scopes. 2. **2. Verdicts** (Week 1-2): We run the checklist per class: injection tests, anonymous-client probes, lockfile and registry checks, credential and tool inventories. Every class gets a yes or no with the evidence, and the findings that come out carry a reproduction. 3. **3. Fixes and gates** (Week 2-3): We fix the findings with your team and turn each closed item into a gate: the probe, the test set, the registry rule, the hash check. Each gate is tripped once on purpose to prove it works. 4. **4. Retest and handover** (Week 3): We repeat every class test, record the result next to the original verdict, and hand over the mapping, the checklists and the gates in your pipeline. The catalogue on this page is the reference the next review starts from. ### FAQ **Q: How are incidents selected for the catalogue?** Only cases with a primary source that can be checked: a CVE record, a vendor security bulletin, a public statement from the vendor's leadership, an official post-mortem, or a peer-reviewed study with its method published. Self-reported cases enter only when the vendor confirmed them publicly, and the row says so. Nothing under NDA, including our own engagements. **Q: Our tool is not in the table. Does the catalogue apply to us?** Yes, because the review works on classes, not on product names. A team using a tool that has no public CVE still has untrusted content paths, generated backend rules, new dependencies, agent credentials and tool scopes. We map those and give a verdict per class; the tool name only decides which defaults we check first. **Q: Is this a penetration test?** No. A penetration test attacks a running system from outside, and we do not do that, nor infrastructure, cloud or SOC work. This review reads code and the application layer around the model, reproduces findings against a non-production instance and hands over fixes and gates. If a penetration test is needed afterwards, our findings are a concrete starting point for the specialist doing it. **Q: Does the catalogue prove AI-written code is less secure?** It proves that a tool used without a check in front of it fails in repeatable ways, which is what the studies measure too: Pearce and colleagues, Fu and colleagues and Spracklen and colleagues all describe the output of a model, not the output of a process. Every row has a check that would have caught it, and that check is the point of the page. **Q: What does a retest look like and why is it separate from the fix?** The same test that produced the verdict runs again after the fix: the injection set, the anonymous-client probe, the registry check, the restore drill. The result is written next to the original, so a reader sees a before and an after from the same method. A fix without a retest is a claim; the pair is evidence. **Q: How often is the catalogue updated and can we submit an entry?** It is revised as vendors publish advisories and researchers publish measurements; the source list at the bottom carries the dates. An entry can be added when it has a public primary source, which is also the answer for submissions: send the advisory or post-mortem link, not the story. **Q: What access is needed for the review?** Read access to the repositories in scope, the configuration of the agent tooling (MCP definitions, extension lists, settings files), and a non-production instance for reproductions and probes. No production access and no customer data. Everything runs under NDA, which is also why nothing from client work ever appears in the catalogue. ### Related - https://23minds.com/services/evaluate-audit-secure/security-review - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation ### Sources - CVE-2025-53773, GitHub Copilot and Visual Studio remote code execution (Microsoft, August 2025): https://www.cve.org/CVERecord?id=CVE-2025-53773 - Embrace The Red, GitHub Copilot RCE via prompt injection: settings.json and chat.tools.autoApprove: https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/ - CVE-2025-32711, Microsoft 365 Copilot information disclosure, EchoLeak (June 2025): https://www.cve.org/CVERecord?id=CVE-2025-32711 - CVE-2025-54135, Cursor prompt injection via MCP special files, fixed in 1.3.9 (GitHub advisory): https://github.com/cursor/cursor/security/advisories/GHSA-4cxx-hrm3-49rm - CVE-2025-54136, Cursor MCP definition modification bypasses re-approval (GitHub advisory): https://github.com/cursor/cursor/security/advisories/GHSA-24mc-g4xr-4395 - CVE-2025-54794, Claude Code path restriction bypass, fixed in 0.2.111 (GitHub advisory): https://github.com/anthropics/claude-code/security/advisories/GHSA-pmw4-pwvc-3hx2 - CVE-2025-6514, mcp-remote OS command injection from untrusted MCP servers (JFrog Security Research): https://research.jfrog.com/vulnerabilities/mcp-remote-command-injection-rce-jfsa-2025-001290844/ - CVE-2024-5565, Vanna.AI prompt injection to remote code execution (JFrog Security Research): https://research.jfrog.com/vulnerabilities/vanna-prompt-injection-rce-jfsa-2024-001034449/ - CVE-2023-36189, LangChain SQLDatabaseChain SQL injection: https://www.cve.org/CVERecord?id=CVE-2023-36189 - CVE-2025-48757, insufficient row-level security in Lovable-generated sites; disclosure by Matt Palmer: https://mattpalmer.io/posts/CVE-2025-48757/ - Legit Security, remote prompt injection in GitLab Duo (hidden content, private source exfiltration): https://www.legitsecurity.com/blog/remote-prompt-injection-in-gitlab-duo - Invariant Labs, GitHub MCP server: private repository data leaked through a public issue: https://invariantlabs.ai/blog/mcp-github-vulnerability - General Analysis, Supabase MCP with Cursor: support ticket to integration_tokens leak: https://www.generalanalysis.com/blog/supabase-mcp-blog - Supabase docs, MCP server security: prompt injection, read-only mode, project scoping, feature groups: https://supabase.com/docs/guides/getting-started/mcp - AWS security bulletin AWS-2025-015, Amazon Q Developer for VS Code 1.84.0: https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ - Tracebit, Gemini CLI: code execution and data exfiltration through a README and allowlist bypass, fixed in 0.1.14: https://tracebit.com/blog/code-exec-deception-gemini-ai-cli-hijack - Noma Security, ForcedLeak: Salesforce Agentforce CRM exfiltration through Web-to-Lead and an expired allowlisted domain: https://noma.security/blog/forcedleak-agent-risks-exposed-in-salesforce-agentforce/ - PromptArmor, Google Antigravity exfiltrates data: hidden web text, .env via cat, browser subagent: https://www.promptarmor.com/resources/google-antigravity-exfiltrates-data - The Register, Google Antigravity in Turbo mode deletes a user's drive; Google confirms investigation (December 2025): https://www.theregister.com/2025/12/01/google_antigravity_wipes_d_drive/ - Fortune, Replit Agent deletes a production database during a code freeze; CEO statement and announced fixes (July 2025): https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/ - Wiz Research, Moltbook: exposed Supabase database, 1.5 million API tokens (February 2026): https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys - Lasso Security, AI package hallucinations: the huggingface-cli experiment (March 2024): https://www.lasso.security/blog/ai-package-hallucinations - Spracklen et al., We Have a Package for You! Package hallucinations by code-generating LLMs, USENIX Security 2025 (arXiv 2406.10279): https://arxiv.org/abs/2406.10279 - Fu et al., Security weaknesses of Copilot-generated code in GitHub projects, ACM TOSEM 2025 (arXiv 2310.02059): https://arxiv.org/abs/2310.02059 - Pearce et al., Asleep at the Keyboard? Assessing the security of GitHub Copilot's code contributions, IEEE S&P 2022 (arXiv 2108.09293): https://arxiv.org/abs/2108.09293 --- ## Maintenance debt in AI-assisted code: how to measure it in your own repository and what to do with the result **URL:** https://23minds.com/guides/maintenance-debt-of-ai-written-code > Maintenance debt in AI-assisted code is the extra cost of every later change to code that was produced quickly with an assistant and merged without anyone taking ownership of it. It shows up as duplicated logic, lost change intent, tests that assert the implementation, dependencies nobody chose and modules nobody owns. All five leave traces in git, so all five can be measured before anyone argues about them. ### Summary 23Minds audits maintenance debt in AI-assisted codebases for engineering teams whose delivery got faster and whose changes got slower. The audit computes six metrics from git history and static analysis: relative churn per file, time to first fix after merge, ownership concentration, duplicated and inconsistently changed blocks, critical-path code without effective tests, and survival of issues introduced by assistants. Each metric has published evidence behind it, and the page states where that evidence is mixed. The output is a debt report ranked by cost of change, a remediation plan the team executes itself, and a procedure for handing ownership of unowned modules to named people. Rewriting the code is not part of the audit. ### Who it's for - CTOs and VPs of Engineering who adopted coding assistants across the team and now see lead time for changes going up - Engineering managers inheriting a codebase where a large share of the code has no human author who remembers why it looks that way - Tech leads asked to put a number on the debt before the next planning cycle, with nothing but a feeling to show - Teams hiring for or budgeting AI code remediation as a category of work and needing a scope for it ### Where the cost comes from The evidence on AI-assisted code is mixed. In a controlled experiment with 151 participants, 95% of them professional developers, Borg and colleagues (Echoes of AI, 2025) observed no consistent warning signs of degraded code-level maintainability when other developers evolved AI-assisted code. In the wild the picture is different: Liu and colleagues (Debt Behind the AI Boom, 2026) tracked 302.6k verified AI-authored commits across 6,299 repositories and found that more than 15% of commits from every assistant introduced at least one static-analysis issue, and that 22.7% of those issues still survive in the latest revision. The 2025 DORA report, drawn from nearly 5,000 respondents, reports a positive relationship between AI adoption and throughput and a persistently negative one with delivery stability. Read together: the variable is the process around the tool, and the only way to know which side your repository is on is to measure it. Five mechanisms account for most of the cost, and each is a property of the tool used without a process. An assistant sees the files in its context window, so it adds a helper or a branch next to existing structure instead of reusing what lives two directories away. A pull request description generated from the diff records what changed but not why, so the intent of the change is gone the day it merges. Tests generated from the implementation assert the current behaviour, bug included, and report high coverage while catching nothing. A dependency appears because the model has seen it often, not because anyone on the team decided to carry it. And a file touched by five people and their assistants has no owner, which Bird and colleagues (2011) showed correlates with both pre-release and post-release failures on Windows Vista and Windows 7. A multivocal review of 104 sources by Ehsani and colleagues (2026) gives this last one a name: provenance debt, the point where responsibility for generated logic cannot be traced to anyone. Sawada and colleagues (2026) analysed about 1,000 AI-generated files across 100 popular repositories and found that they receive less frequent maintenance than human-authored code, that the changes they do receive are mostly feature extensions rather than fixes, and that humans perform almost all of that maintenance. A file that keeps growing and is never corrected is not necessarily healthy. It may simply be a file nobody dares to touch. ### Six metrics you can compute from git and static analysis None of the metrics below needs a commercial platform. They need read access to the repository, the CI logs and a static analysis run. Each one has a published reason to be trusted, so nobody has to take the auditor's word for the result. There is no universal alarm threshold for any of them, and this page does not invent one. The comparison that holds is against your own repository before assistants arrived, or between modules written with and without them. | Metric | How it is computed | Why it can be trusted | What a bad reading looks like | | --- | --- | --- | --- | | Relative churn per file | Lines changed per file per period, divided by file size, from git log | Nagappan and Ball (ICSE 2005): relative churn measures are highly predictive of defect density, absolute churn is not | Files whose relative churn keeps rising after the assistant was adopted, with no matching feature work | | Time to first fix after merge | For each merged change, days until the next commit touching the same lines that references a bug, a revert or a hotfix | Direct measure of the stability DORA reports as the cost of higher change volume without control systems | A shortening interval, or a cluster of fixes landing within days of merges from one part of the team | | Ownership concentration | Share of commits held by the top contributor per module, and the count of contributors below a small share, from git blame and log | Bird and colleagues (FSE 2011): number of low-expertise contributors and top-owner share relate to pre-release faults and post-release failures | Modules where the top owner holds a shrinking share and the long tail of minor contributors keeps growing | | Duplicated and inconsistently changed blocks | Clone detection across the repository, then a diff of each clone group to find copies that were changed in one place only | Juergens and colleagues (ICSE 2009): 107 developer-confirmed faults from inconsistent clone changes across five commercial and open-source systems | Clone groups with a bug fix applied to some copies and not others | | Critical-path code without effective tests | Coverage restricted to the paths that handle money, identity and data, then mutation testing on those paths | Coverage alone says a line was executed; the mutation score says a test would notice if the line were wrong | High line coverage with a low mutation score on the paths that matter | | Survival of assistant-introduced issues | Static analysis before and after each assistant-authored commit, then tracking each introduced issue to the current revision | The method Liu and colleagues (2026) used on 302.6k commits; it separates issues that get fixed from issues that accumulate | A growing backlog of introduced issues that are never closed, concentrated in unowned modules | ### AI code remediation as a category of work, and where the audit stops In discussions among experienced developers, remediation of AI-assisted code has become a job description: people are hired specifically to take over code nobody wrote and make it changeable again. The audit scopes that work: it produces the ranked list, the plan and the ownership handover, and does not execute the rewrite, for two reasons. The team that has to live with the code should be the one that restructures it, or the intent is lost a second time. And the audit is only worth something if the auditor has nothing to gain from a large remediation estimate. The scope, stated plainly, so that it can be compared with other offers: - In scope: the six metrics above computed on your repository, with the scripts left behind so the team can re-run them - In scope: a debt report ranked by cost of change, where each item names the module, the mechanism and the metric that exposed it - In scope: a remediation plan with an order of work, an owner per item and a definition of done expressed as a measurement - In scope: a procedure for handing ownership of unowned modules to named people, with a deputy and a review date - Out of scope: rewriting, refactoring or migrating the code; that is a separate purchase, from 23Minds or from anyone else, and the report is written so that it can be handed to either - Out of scope: infrastructure, cloud configuration and penetration testing; the audit reads the repository, not the environment it runs in ### Where this goes wrong, and what we do about it **Duplication instead of reuse** The assistant works on the files in its context. When a similar helper exists elsewhere in the repository it does not know, so it writes a second one, or adds a branch to the structure it can see. After a few months the same validation, retry or mapping logic lives in four places with small differences. A fix then lands in one of them and the other three keep the bug, which is exactly the inconsistent clone change that Juergens and colleagues traced to confirmed faults. What we do about it: We run clone detection across the whole repository, not per pull request, and diff every clone group to find copies that were changed in one place only. Each inconsistent group gets a verdict with the team: intentional divergence, or a fix that missed its siblings. The ones that touch critical paths are fixed first, and the detector runs again after the fix to confirm the group is consistent. The team keeps the detector configuration so the next report is comparable. What stays with you: clone register with every inconsistent group, its verdict and its priority, plus the detector configuration **Lost change intent** The pull request description is generated from the diff, so it explains what changed and never why. The prompt that produced the change is not stored anywhere, and the ticket says only what the user wanted, not what trade-off the engineer accepted. Six months later a reader can see that a timeout was set to eleven seconds and has no way to learn whether that was a decision or a default. The next change either preserves the accident or breaks the decision. What we do about it: We take a sample of merged changes from the period after assistants were adopted and trace each one back to a ticket, a prompt or a recorded decision. The share that cannot be traced is the number the team needs. We then add a change-record convention to the pull request template, one line of intent and the constraint it satisfies, and re-sample after a quarter to verify the share moved. What stays with you: intent traceability sample with the untraceable share, and the amended pull request template **Tests written to the implementation** Asked to add tests, the assistant reads the code it just wrote and asserts what it does, including the mistake. Line coverage on the module goes up, the dashboard turns green, and the tests would pass just the same if the logic were wrong. The team believes the module is protected and reduces review on later changes to it. What we do about it: We restrict the question to the critical paths and run mutation testing there: small deliberate faults injected into the code, then a count of how many the suite catches. Tests that catch nothing are listed by name. We rewrite the ones on critical paths from the requirement rather than from the code, together with your team, and re-run the mutations to verify the score changed. What stays with you: mutation score per critical path, before and after, with the list of tests that caught no mutants **Dependencies nobody chose** A package appears in the lockfile because the model has seen it in enough training data to suggest it, not because anyone compared it with what the repository already had. The result is two HTTP clients, three date libraries and a utility that duplicates a function from the standard library, each carrying its own upgrade cadence and licence. When a vulnerability notice arrives, nobody knows who owns the decision to keep or drop the package. What we do about it: We diff the dependency manifest before and after assistants were adopted, and for each addition record whether it overlaps an existing dependency, when it was last released, and its licence. Every dependency gets an owner and a verdict: keep, replace, remove. We verify the removals build and pass the suite, and leave the log with the team so the next addition is a decision rather than a suggestion. What stays with you: dependency decision log with an owner and a verdict per package **No module owner** With an assistant, every engineer can touch every module, and does. Ownership concentration falls, the count of minor contributors per file grows, and the person who could answer a question about the module is nobody, because the last five changes came from five different people each working with the tool. Bird and colleagues found this pattern related to failures long before assistants existed; assistants only make it cheaper to produce. What we do about it: We build an ownership map from git for every module, compute the top-owner share and the minor-contributor count, and flag modules where both point the wrong way. For each flagged module the team names an owner and a deputy, and the handover is a written procedure with a review date. We recompute the map after a quarter to verify the shares moved. What stays with you: ownership map per module with named owner and deputy, and the handover procedure ### What you get - Metrics baseline for the six measures, with the scripts and configuration so the team can re-run them - Debt report ranked by cost of change, each item naming the module, the mechanism and the metric that exposed it - Remediation plan with an order of work, an owner per item and a measured definition of done - Ownership handover procedure for unowned modules, with owner, deputy and review date - Dependency decision log with a verdict per package added since assistants were adopted - Written scope boundary stating what the audit did not cover, so the report can be handed to whoever does the rewrite ### How we work 1. **1. Baseline from git** (Week 1): With read-only access we compute churn, time to first fix and ownership for every module, and agree with your team which paths count as critical. At this stage there are only numbers and the period they cover. 2. **2. Static analysis, clones and mutations** (Week 1-2): We run clone detection, issue tracking across assistant-authored commits and mutation testing on the critical paths. Each finding is tied to a module and a metric. 3. **3. Report and priorities** (Week 2-3): We rank the findings by cost of change and walk them with the people who maintain the code. Where the team disagrees with a ranking, the disagreement goes into the report with its reason. 4. **4. Ownership handover and re-measurement** (Week 3, then one re-measurement after a quarter): We hand over the plan, the procedure and the scripts, and come back after a quarter to recompute the baseline and report what moved. ### FAQ **Q: Is AI-assisted code really more expensive to maintain?** The published evidence does not settle it. A controlled experiment with 151 participants found no consistent warning signs of degraded maintainability; a study of 302.6k assistant-authored commits in real repositories found that 22.7% of the issues they introduced never got fixed. The difference is the process around the tool. That is why we measure your repository instead of quoting either study at you. **Q: Can our team compute these metrics without an audit?** Yes, and the scripts we leave behind exist so that you can. What the audit adds is the priority call made by someone with no stake in the size of the remediation, the mutation and clone runs set up correctly the first time, and a report your engineers did not have to write about their own work. **Q: What is an alarming level for any of these metrics?** There is no published universal threshold and we will not invent one. The comparison that holds is your own repository before assistants arrived, or modules written with and without them over the same period. A metric moving in the wrong direction quarter over quarter is the alarm. **Q: Do you refactor or rewrite the code you find?** No. The audit produces the ranked report, the remediation plan and the ownership handover. The rewrite is a separate piece of work, done by your team, by us under a separate engagement, or by anyone else you choose, and the report is written so it can be handed to any of them. **Q: What access do you need?** Read-only access to the repository history, the CI logs and the dependency manifests, plus a way to run static analysis and mutation testing on a copy. We do not need production access, and the audit does not touch infrastructure. **Q: How long does it take?** About three weeks for a single repository of typical size, with one re-measurement after a quarter. A monorepo or several services take longer, and we say how much longer after the first day of baseline work rather than before. **Q: Does this cover security issues in the generated code?** Static analysis flags security issues alongside code smells, and they go into the report. The security review of the code and its dependencies is a separate practice with its own scope, and we point to it rather than folding it in. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/operate-measure-maintain/app-maintenance - https://23minds.com/services/evaluate-audit-secure/test-coverage ### Sources - Liu et al., Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild (arXiv:2603.28592, 2026): https://arxiv.org/abs/2603.28592 - Borg et al., Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability (arXiv:2507.00788, Empirical Software Engineering 2026): https://arxiv.org/abs/2507.00788 - Sawada et al., To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study (arXiv:2605.06464, 2026): https://arxiv.org/abs/2605.06464 - Ehsani et al., Faster Code, Deeper Debt? A Multivocal Literature Review on Technical Debt in LLM-Assisted Software Development (arXiv:2606.14796, 2026): https://arxiv.org/abs/2606.14796 - Google Cloud, Announcing the 2025 DORA Report: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report - Bird et al., Don't Touch My Code! Examining the Effects of Ownership on Software Quality (ESEC/FSE 2011): https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/ - Nagappan and Ball, Use of Relative Code Churn Measures to Predict System Defect Density (ICSE 2005): https://www.microsoft.com/en-us/research/publication/use-of-relative-code-churn-measures-to-predict-system-defect-density/ - Juergens et al., Do Code Clones Matter? (ICSE 2009): https://teamscale.com/publications/2009-do-code-clones-matter.pdf --- ## Model swap regression harness: a case set with expected decisions that blocks a retirement migration before it reaches production **URL:** https://23minds.com/guides/regression-harness-for-model-swaps > A model swap regression harness is a versioned set of real cases, each with the decision the agent is expected to take and a tolerance for that decision, run before and after any change of model, prompt or tool, with a threshold that blocks the change from shipping. It exists because when a provider retires a model or a team moves to a cheaper one, the thing that regresses is what the agent did, and a reviewer reading sample outputs will not see it. ### Summary 23Minds builds model swap regression harnesses for engineering teams that run LLM agents in production and have to move to a new model on a provider's retirement schedule or on their own cost decision. The harness records the expected decision and tool calls for every case, runs the old and the new model on the same cases, and reports a diff of decisions, tool calls, cost and latency, with a threshold agreed before the run that blocks the swap when it is crossed. The same harness runs on every prompt and tool change, because the published evidence shows agents changing behaviour without any change to the model identifier. The client keeps the case set, the diff report for each swap, the CI job that runs it, and a written procedure for retirement notices with a rollback path. ### Who it's for - CTOs and VPs of Engineering who received a retirement notice for the model behind a production feature and need to know what the replacement will do differently before the date - Platform teams that call models through an alias or a latest tag and have seen behaviour change with no deploy in their own history - Owners of agents that book, cancel, refund or refuse on the customer's behalf, where a changed decision is a changed transaction - Teams asked by finance to move to a cheaper model who cannot say what the cheaper model will stop doing ### What a model swap changes, and why sample outputs do not show it An agent in production is a loop of decisions: whether to call a tool, which one, with which arguments, whether to ask the user, whether to refuse, whether to stop. The text it returns is the last step. After a swap the text is what a reviewer reads, and a newer model's text usually reads better: cleaner, more confident, better formatted. The regression lives in the decisions. A thread on a developer forum in July 2026 describes a swap that silently broke an agent's cancellations; a second thread from August 2026 recounts a case where the replacement model, asked to check availability, booked the meeting on its own. In both cases the outputs looked fine and the state of the world was wrong. Agent evaluation research arrived at the same place. Yao and co-authors (2024), who built tau-bench, score an agent by comparing the database state at the end of the conversation with an annotated goal state, and introduced pass^k, the probability that the agent succeeds on all k of k repeated runs of a task, because a single run hides inconsistency. Their best agent at the time succeeded on under 50% of tasks and had pass^8 below 25% in the retail domain. A harness that scores the final text with a rubric measures the wrong layer. It has to assert on the decision and on the end state, and it has to run each case more than once. ### Outcome drift and execution drift Two different things get called drift, and they need different controls. Outcome drift is the model producing a different decision on the same input because the model changed: a retirement migration, a swap to a cheaper tier, an alias that now points somewhere else. Execution drift is the same model identifier producing different behaviour because something behind the identifier changed. Chen, Zaharia and Zou (2023) measured the same GPT-4 endpoint in March and June 2023 and found accuracy at identifying prime numbers dropping from 84% to 51%, with instruction following degrading and more formatting mistakes in generated code. OpenAI's own documentation for the seed parameter says determinism is best effort and that the system_fingerprint field, which represents the backend configuration the model runs with, changes when the provider updates the numerical configuration of the infrastructure serving the model. The practitioner workaround, repeated in every thread on the subject, is to log the model identifier and fingerprint the provider returns with each response and alert on change. That is a good observability control and it belongs in the tracing layer, next to cost and latency per call. A harness is a different instrument. The log says that something changed and nothing about what the agent now does differently, and it stays silent when the identifier is unchanged and the behaviour moves anyway. The harness answers that question; the logged identifier says when to run it outside the release cycle. ### How the three main providers retire models Notice periods and alias mechanics differ per provider, and the differences decide how much of a migration is under the team's control. The table summarises what each provider's documentation states at the time of writing; specific dates change and are not reproduced here. | Provider | Lifecycle states | Stated notice before shutdown | Aliases and pinning | | --- | --- | --- | --- | | Anthropic | Active, legacy, deprecated (still works, replacement named), retired (requests fail) | At least 60 days for publicly released models; email plus documentation | Dates apply to Anthropic-operated platforms; Bedrock and Vertex set their own schedules. Some request parameters are deprecated with newer models and return an error, so a swap can break a request rather than change its behaviour | | OpenAI | Legacy (no updates), deprecated (retirement announced), shut down (endpoint gone) | At least six months for generally available models, three months for specialised variants, as little as two weeks for previews | Dated snapshots and aliases that point at a snapshot; pinning the snapshot fixes the version, the alias moves | | Google Gemini | Experimental, preview, stable, deprecated, shut down; listed dates are the earliest possible | Previews deprecated with at least two weeks' notice; a latest alias is hot-swapped on every release, with two weeks' email notice for breaking changes | Stable versions usually do not change and are recommended for production; latest can point at a preview or experimental release | ### The harness: cases, expected decisions, tolerance, threshold A case is a recorded real interaction: the input, the tool responses replayed from a fixture so the environment does not vary, the expected decision, the expected tool calls with the arguments that matter, and the end state. Cases come from production traces, stratified so that the rare and expensive ones are present: refusals, irreversible actions, escalations to a person, edge cases from previous incidents. Each case carries a tolerance. A cancellation case tolerates no change in the decision and no change in the order identifier passed to the tool; a summarisation case tolerates different wording and asserts only that the named facts appear. Text criteria that need a judge model use one, and that judge needs its own calibration against human raters, which is the subject of a separate guide on this site and is not repeated here. The threshold is written before the run, per case class, not after the diff is read. Classes with irreversible actions get zero tolerance: one changed decision blocks the swap. Classes with reversible outcomes get a share of cases that may change, agreed with the owner of that flow. Each case runs several times per model so the comparison is pass^k against pass^k, and a case that passes once and fails twice on the new model counts as inconsistent, which for an agent acting on a customer's behalf is a regression. Kapoor and co-authors (2024) argue that agent evaluation without cost is incomplete and that benchmarks without holdouts get overfitted; the harness reports cost and latency per case next to the decision diff, and a slice of cases is held back from anyone tuning the prompt for the new model. - Triggers: model or version change, prompt change, tool schema or description change, and a change in the model identifier or fingerprint logged in production. - Diff per case: expected versus observed decision, tool calls and arguments, end state, tokens and cost, latency, consistency across repeated runs. - Gate: threshold per case class agreed in writing before the first run; crossing it fails the CI job and the swap does not ship. - The confidence trap: the new model's text is hidden from reviewers until the decision diff has been read, so a more assured tone cannot be mistaken for a better decision. ### The swap procedure and the rollback path A retirement notice starts a procedure that already exists. The case set is frozen at the notice date and tagged with the old model's version identifier, and the old model's results on it are recorded as the baseline while the old model still answers. The replacement is run on the same frozen set; the diff report goes to the owner of each flow with the failed cases attached. Prompt changes made to fit the new model are versioned separately and run through the harness again, because a prompt fix for one case class often moves another. The swap ships behind a switch that can point back at the old model until its retirement date, so a regression found in production has a rollback that takes minutes, with no hotfix. After the retirement date there is nowhere to roll back to, which is the argument for starting when the notice arrives rather than the week before. The procedure also names who watches the providers' deprecation pages and release notes, at what cadence, and where the next known dates are kept. A team that has done this once has the case set, the CI job and the diff format; the second migration takes a run and a diff review. ### Where this goes wrong, and what we do about it **The swap is validated on text quality and the decision changes** The team compares sample outputs from the old and the new model, reads the new ones as cleaner and better structured, and ships. The cases where the agent should have asked, refused or stopped are not in the sample, or are in it but the reviewer reads the prose rather than the tool call. The cancellation that no longer happens, or the meeting that gets booked instead of checked, is found by a customer. What we do about it: We record the expected decision, tool calls and end state for every case, and the diff is computed on those fields before anyone reads the text. Cases from the classes with irreversible actions are oversampled from production traces. The reviewer sees the decision diff first and the text second. What stays with you: case set with expected decisions and tool calls per case, and a decision diff report per swap with the failed cases attached **The alias moved and nobody deployed anything** The application calls the model through an alias or a latest tag. The provider points the alias at a new release, within its stated notice period or, for backend configuration changes, with no notice at all. Behaviour changes on a day with no deploy in the team's history, and the investigation starts in the application code. Chen, Zaharia and Zou (2023) documented behaviour of the same endpoint moving substantially within three months. What we do about it: We pin the model to a fixed version where the provider offers one, log the model identifier and fingerprint returned with every response into the tracing layer, and add an alert on change. A changed identifier triggers a harness run outside the release cycle, so the team sees the decision diff the same day rather than a symptom weeks later. What stays with you: pinned version in configuration, identifier and fingerprint fields in every trace, and an alert wired to a scheduled harness run **The newer model sounds more confident, so it is read as better** One engineer runs a handful of prompts through both models and prefers the new one because it hedges less and formats better. Confidence in the text is taken as evidence of a better decision. In the case recounted by practitioners, the more assured model went a step further than asked and booked the meeting; the tone was the reason it was not questioned. What we do about it: We compute the decision-level pass rate and the consistency across repeated runs per case class, with the text hidden until the diff has been read. Where the new model acts beyond what the case asked for, the case fails regardless of how the response reads, and the finding goes into the prompt work for the new model with the case attached. What stays with you: per-class pass rate and pass^k for both models on the same frozen case set, reviewed before any output text **The threshold is set after the result is known** The harness runs, the new model passes 92% of cases, and 90% is declared acceptable in the same meeting. The 8% includes two refusal cases and a refund case, which nobody looks at individually because the aggregate cleared. The threshold has become a description of the result rather than a gate. What we do about it: We write the threshold per case class with the owner of each flow before the first run, and classes with irreversible actions get zero tolerance. The CI job fails on any class over its threshold and lists the failed cases by class, so a refund case cannot hide behind a hundred passing summaries. What stays with you: threshold register per case class with owner and date, and a CI job that fails on it **The harness runs on model changes only, and a tool edit slips through** A developer reorders the tool list, renames a parameter or rewrites a tool description during an unrelated ticket. The model's choice of tool depends on those descriptions, so the agent starts picking a different tool on the same input. No model changed, so the harness was not run, and the regression is attributed to the model at the next swap. What we do about it: We hash the model version, the prompt and the tool schemas together and run the harness whenever any of the three changes, in the same CI job. The diff report names which of the three changed since the baseline, so the cause is in the report rather than in a bisect. What stays with you: combined hash of model, prompt and tools recorded with every harness run, and a CI trigger on any of them ### What you get - Case set: real interactions from production traces with replayed tool fixtures, expected decision, expected tool calls and arguments, expected end state and tolerance per case, stratified by case class and versioned with the model, prompt and tool hash - Threshold register: one row per case class with the tolerance, the owner and the date it was agreed, wired into the CI job as a blocking gate - Diff report per swap: decision, tool call, end state, cost and latency differences between baseline and candidate, pass^k per class, failed cases attached, hidden output text until the diff is read - CI job that runs the harness on model, prompt or tool change and on an identifier change logged in production, with the combined hash recorded per run - Tracing fields for the model identifier and backend fingerprint returned per response, with an alert on change and a scheduled harness run behind it - Retirement procedure: who watches which provider pages and at what cadence, the freeze and baseline steps at notice time, the switch that points back at the old model until its retirement date, and the rollback path ### How we work 1. **1. Case classes and threshold register** (Week 1): We map the agent's decisions and tools with you, name the case classes, and write the tolerance and the owner for each class before any run. Irreversible actions, refusals and escalations get their own classes with zero tolerance. This is the document the gate will enforce. 2. **2. Case set from production traces** (Week 1-3): We sample real interactions from your traces, stratified by class, record the tool fixtures so the environment replays identically, and label the expected decision, tool calls and end state per case with your flow owners. A holdout slice is set aside from anyone tuning prompts. 3. **3. Baseline and first diff** (Week 3-4): We run the current model several times per case to record the baseline and pass^k per class, then run the candidate model on the same frozen set. The first diff report goes to the flow owners with the failed cases, cost and latency per class. 4. **4. CI wiring and production hooks** (Week 4-5): We add the harness as a CI job triggered by the combined hash of model, prompt and tools, add the identifier and fingerprint fields to your traces with the alert and the scheduled run behind it, and put the model switch with the rollback path into configuration. 5. **5. Retirement procedure and handover** (Week 5-6): We write the procedure with your team: who watches the providers' pages, what happens at notice time, and how a swap ships and rolls back. We run one swap end to end with you on the harness and leave the case set, the register and the report format in your repository. ### FAQ **Q: We pin our model to a fixed version. Do we still need the harness?** Pinning removes the alias problem and leaves the retirement problem, because a pinned version still gets a retirement date and then stops answering. The harness is what tells you what the replacement does differently on your cases before that date. Pinning also does not cover backend configuration changes behind the same identifier, which is why the returned identifier and fingerprint go into your traces alongside the pin. **Q: How many cases does the set need?** Enough per case class that a threshold on that class is meaningful, with the irreversible classes oversampled because they are rare in traffic and expensive when wrong. There is no universal number; the size is fixed per class in step 1 from what a changed decision in that class costs you. The set grows after every incident, because an incident is a case the set was missing. **Q: Can we use an LLM judge to score the cases?** For decisions, tool calls and end state, no judge is needed: those are compared as values. A judge is needed for text criteria such as whether a summary contains the named facts, and that judge has to be calibrated against your own raters and pinned to a version, otherwise a swap of the judge shows up as a swap of the product. We describe that calibration in a separate guide and reuse it here rather than rebuilding it. **Q: Our provider gave 60 days. Is that enough?** It is enough for a team that has the case set and the CI job, because the migration is then a run, a diff review and prompt work on the failed classes. It is tight for a team starting from nothing, which is why the first engagement builds the harness on the current model before any notice arrives. After that, the notice period is spent on the diff rather than on building the instrument. **Q: The cheaper model fails 6% of cases. Do we swap or not?** It depends on which classes the 6% sit in, which is why the threshold is per class. Six percent spread over summaries with different wording is a swap with a prompt adjustment. Six percent that includes one refund or one refusal case blocks the swap until those cases pass, whatever the saving. The report lists the failed cases by class so the decision is made on the cases, and the cost and latency columns show what the swap buys. **Q: What do we do when the harness fails on a change we did not make?** That is the execution drift case: the logged identifier or fingerprint changed, or neither did and the behaviour moved anyway. The scheduled run gives you the decision diff the same day. From there the options are the same as for a planned swap: prompt work on the failed classes, a pinned version if the provider offers one, or a move to the replacement model with the harness as the gate. **Q: Does this cover the prompt and tool changes we make ourselves?** Yes, and that is most of what the harness catches after the first swap. The CI job triggers on the combined hash of model, prompt and tool schemas, and the report says which of the three changed. A renamed tool parameter can move decisions as much as a model swap does, and a trigger on model changes alone would never run for it. ### Related - https://23minds.com/services/operate-measure-maintain/llm-observability - https://23minds.com/services/evaluate-audit-secure/ai-quality-evaluation ### Sources - Anthropic, Model deprecations: lifecycle states, at least 60 days' notice for publicly released models, partner platforms on their own schedules, deprecated request parameters returning errors on newer models: https://platform.claude.com/docs/en/about-claude/model-deprecations - OpenAI, Deprecations: deprecation versus shutdown, notice of at least six months for generally available models, three months for specialised variants and as little as two weeks for previews, dated snapshots and aliases: https://developers.openai.com/api/docs/deprecations - Google, Gemini API model deprecations: listed shutdown dates are the earliest possible, replacement models named per deprecation: https://ai.google.dev/gemini-api/docs/deprecations - Google, Gemini models: version name patterns, stable versions usually do not change, latest alias hot-swapped on every release with two weeks' email notice for breaking changes, previews deprecated with at least two weeks' notice: https://ai.google.dev/gemini-api/docs/models - OpenAI Cookbook, Reproducible outputs with the seed parameter: best-effort determinism and system_fingerprint as the backend configuration the model runs with: https://developers.openai.com/cookbook/examples/reproducible_outputs_with_the_seed_parameter - Chen, Zaharia and Zou (2023), How is ChatGPT's behavior changing over time?: same endpoint in March and June 2023, prime identification from 84% to 51%, instruction following and code formatting degrading: https://arxiv.org/abs/2307.09009 - Yao et al. (2024), tau-bench: A Benchmark for Tool-Agent-User Interaction: evaluation by comparing end database state with the goal state, the pass^k consistency metric, best agent under 50% success and pass^8 below 25% in retail: https://arxiv.org/abs/2406.12045 - Kapoor et al. (2024), AI Agents That Matter: cost as a metric alongside accuracy, holdout sets against benchmark overfitting, reproducibility of agent evaluation: https://arxiv.org/abs/2407.01502 --- # Train, Adopt & Govern (anchor 01) **URL:** https://23minds.com/services/train-adopt-govern **Highlight:** Funded pathways (BUR/PARP) > AI training for engineering and business teams, rules for using AI at work that legal and security can sign off, and the technical side of EU AI Act compliance. Selected programs are eligible for BUR co-funding in Poland. ### Summary AI Institute, the training area of 23Minds, runs AI training in coding with AI, automating everyday work and using AI tools safely. Programs are designed and taught by engineers who build software with AI and audit AI-written code. Tracks: engineering on AI coding tools, business on automation and safe day-to-day use, leadership on rollout planning and measuring return. The governance basics are four documents: an AI usage policy, an approved-tools list, an evaluation schedule and risk-register entries, with acceptance criteria agreed with legal and procurement. The technical side of EU AI Act compliance covers system inventory, risk classification and technical documentation, and its scope depends on the system and on your role under the regulation. Article 4 of the AI Act on AI literacy has applied since 2 February 2025, and obligations for high-risk systems listed in Annex III apply from 2 December 2027. Selected training programs are eligible for co-funding from Poland's Development Services Database (BUR), under operator rules. IT training and consulting fall within the company's ISO 9001:2015 certificate (DNV, no. 10000439701-MSC-RvA-POL, valid until 3 March 2027). ### Who it's for - Engineering leaders rolling out AI coding assistants across their teams - L&D and HR leaders procuring practical AI training under BUR/PARP funding - Heads of operations who need agreed rules for using AI across the team - Business owners buying AI training for their team who want to know what the team keeps afterwards ### Problems we solve - Teams are using AI tools ad-hoc with no shared standards or evaluation - Procurement and legal block AI rollout because there is no governance baseline - The training budget is there, but it is hard to tell whether the team uses AI in daily work afterwards - Tools are licensed but adoption stalls past the early enthusiasts ### Practices under this anchor - AI Training for Developers - https://23minds.com/services/train-adopt-govern/ai-training-programs - AI Usage Policy - https://23minds.com/services/train-adopt-govern/ai-governance-basics - EU AI Act Technical Compliance - https://23minds.com/services/train-adopt-govern/eu-ai-act-compliance ### FAQ **Q: Can the training be publicly funded?** Selected AI training programs are eligible for co-funding from Poland's Development Services Database (BUR), depending on company size, region and the operator's current rules. We check it with you on the intro conversation, before you plan anything. **Q: Do you train developers or business users?** Both. Engineering tracks focus on AI-assisted development workflows, code evaluation and production patterns. Business tracks focus on workflow automation, prompt design and safe use of AI tools day to day. **Q: What governance do you put in place?** The procurement-ready baseline: an AI usage policy, an approved-tools list, an evaluation cadence for outputs that touch production, and a basic risk register. Not a heavy framework - enough for legal and security to sign off. **Q: How long does a typical engagement take?** Workshops are priced per day, for one team of up to 12 people or an online lecture with no attendee limit, and we pick the number of days to fit the team. A cohort program runs 4 to 6 weeks with weekly sessions. The AI usage rules package closes within 3 weeks and the AI Act gap analysis within 4, counting from the day the scope is agreed. **Q: What outcomes do you measure?** The share of the team using the tools after training, time saved per person per week, the share of code changes prepared with AI, and the result of a check against your own rules. We agree the specific metrics on the intro conversation. Adoption alone says little: in the 2025 DORA report, 90% of respondents used AI at work, while 30% had little or no trust in the quality of AI output. **Q: Which AI Act dates apply to our company?** The dates depend on your role and on how your AI systems are classified, and the legal reading is one to confirm with your lawyer. Article 4 (AI literacy) and the prohibitions in Article 5 have applied since 2 February 2025, obligations for general-purpose AI models since 2 August 2025, and the transparency duties in Article 50 since 2 August 2026. Regulation (EU) 2026/1744 amended the wording of Article 4 from 27 July 2026 and moved the obligations for high-risk systems to 2 December 2027 for Annex III and 2 August 2028 for AI in regulated products. In Poland, the Act of 3 July 2026 on artificial intelligence systems (Journal of Laws 2026 item 1003) has been in force since 11 August 2026, and its provisions on individual opinions, inspections and penalties apply from 28 October 2026. --- ## AI Training for Developers - Train & Adopt **URL:** https://23minds.com/services/train-adopt-govern/ai-training-programs **Service type:** Professional training **Anchor:** Train, Adopt & Govern (Train & Adopt) > Role-specific AI training that teams actually apply at work - engineering, design, operations and leadership tracks, workshop or multi-week cohort format. ### Summary 23Minds delivers AI training programs designed by practitioners who ship AI in production. Engineering tracks cover AI-assisted development with current tools (Claude Code, Cursor, Copilot, Aider), code evaluation patterns and production safeguards. Business tracks cover prompt design, workflow automation and safe use of AI tools day to day. Leadership tracks cover adoption roadmaps and ROI measurement. A training day has a fixed price: a workshop for a team of up to 12 or an online lecture with no attendee limit; 4-6 week cohorts are quoted as a project; selected programs are eligible for BUR/PARP funding in Poland. The AI literacy duty in Article 4 of the EU AI Act has applied since 2 February 2025. ### Who it's for - Engineering managers rolling out AI coding assistants across their teams - L&D heads procuring practical AI training under BUR/PARP funding rules - Product designers and PMs upgrading their day-to-day AI workflow - C-suite leaders building company-wide AI literacy ### Problems we solve - Generic vendor AI training does not translate to your codebase or workflows - Engineers use AI tools but cannot tell colleagues what good looks like - Training budget is allocated but no provider has shipped what they teach - Cohort vs workshop format choice unclear given team size and goals ### What you get - Role-specific curriculum tuned to your stack, tools and use cases - Live workshop delivery (in-person Warszawa/Szczecin or remote) - Hands-on lab exercises tied to your actual codebase or workflows - Recorded sessions and a written reference playbook per track - Post-program check-in 4-6 weeks later to measure adoption ### How we work 1. **1. Scope call** (Week 0): Confirm audience, current AI tool usage, business goals and funding eligibility. 2. **2. Curriculum design** (Week 1-2): Tailor agenda, choose tools to cover, prepare codebase-specific lab material. 3. **3. Delivery** (Workshop days as the team needs, or 4-6 weeks (cohort)): Run the workshop or cohort. Hands-on labs, Q&A, working sessions with real client problems. 4. **4. Adoption check-in** (Week +4-6): Measure post-training usage, identify blockers, recommend next-step interventions. ### FAQ **Q: What is the difference between workshop and cohort format?** A workshop is an intensive program counted in days and priced per day - best for kicking off adoption fast. Cohorts spread across 4-6 weeks with weekly sessions and homework - best for changing day-to-day habits in larger teams. **Q: Can the training cover our actual codebase?** Yes. Lab exercises are built from your repos under NDA. Engineers learn AI-assisted patterns directly against the code they will work on tomorrow. **Q: Is BUR/PARP funding available?** Selected programs qualify for funded development pathways (BUR/PARP) in Poland. Eligibility depends on company size, sector and current operator rules. We help check eligibility on the intro call. The labour minister's priorities for Poland's National Training Fund (KFS) in 2026, published on 25 September 2025, name AI skills in the priority on new processes, technologies and tools at work. **Q: What tools do you cover?** Current production-grade AI coding assistants: Claude Code, Cursor, Copilot, Aider, Windsurf. We also cover prompt design and LLM workflow tooling (n8n, Zapier with LLM, custom agents) for business tracks. **Q: How do you measure if the training worked?** Pre/post adoption survey, AI-assist time tracked per developer-week, percentage of PRs touched by AI tools, and a post-program code-quality check-in. Specific metrics agreed on the scope call. **Q: Why train a team that already uses AI tools?** In Stack Overflow's 2025 survey, 84% of the developers who answered the question used or planned to use AI tools. Among those answering the trust question, 46% distrusted the accuracy of the output, and among those answering the frustration question, 66% named answers that are almost right, but not quite. In the 2025 DORA report, 90% of respondents used AI at work and 30% had little or no trust in the quality of AI output. The engineering track covers reviewing AI-generated changes, tests that fail when behaviour breaks, and protecting secrets and managing permissions. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation --- ## AI Usage Policy - Train & Adopt **URL:** https://23minds.com/services/train-adopt-govern/ai-governance-basics **Service type:** Governance and compliance consulting **Anchor:** Train, Adopt & Govern (Train & Adopt) > The procurement-ready AI governance baseline: an AI usage policy, an approved-tools list, an evaluation cadence and a risk register - enough to unblock legal and security sign-off. ### Summary 23Minds establishes the minimum viable AI governance baseline for organizations rolling out AI internally. The engagement produces an AI usage policy aligned to your industry, an approved-tools list with data-handling rules, an evaluation cadence for AI outputs that touch production, and a basic risk register that legal and security teams accept. The baseline stays small on purpose: the smallest set of artifacts that unblocks AI rollout without creating shelf-ware, with no heavy framework attached. ### Who it's for - Heads of legal and compliance asked to bless an AI rollout - CISOs whose engineering teams want to license AI coding assistants - COOs standing up internal AI use across non-engineering departments - Public-sector and regulated organizations needing a defensible baseline ### Problems we solve - Engineering wants to use AI tools but legal cannot find a precedent to approve - Each team writes its own AI usage rules - inconsistent and unenforceable - Risk register has no entries for AI; auditors flag the gap - Evaluation of AI outputs is informal; nobody can prove quality at audit time ### What you get - Written AI Usage Policy (1 doc, covers staff + contractors) - Approved Tools List with data-handling rules per tool - Evaluation cadence playbook (which AI outputs are reviewed, how, by whom) - Risk register entries for AI use, mapped to your existing risk framework - Quick-reference one-pager for managers to use day to day ### How we work 1. **1. Industry + risk discovery** (Week 1): Interview legal, compliance and engineering leads; understand current risk framework and industry constraints. 2. **2. Draft artifacts** (Week 1-2): Draft AI usage policy, approved-tools list, evaluation cadence and risk register entries. 3. **3. Stakeholder review** (Week 2-3): Walk legal, compliance, security and engineering through the drafts. Iterate. 4. **4. Rollout + training** (Week 3): Train managers on day-to-day application, publish the artifacts internally. ### FAQ **Q: Is this a full AI risk management framework like NIST AI RMF?** No. This is the procurement-ready minimum - enough to unblock AI use and pass standard audits. Organizations with mature risk programs may layer NIST AI RMF, ISO 42001 or similar on top later. We can scope that as a follow-up. **Q: Will the policy account for our industry rules?** Yes. We tailor policies to your industry - fintech (KNF/MiFID/DORA-relevant), healthcare (GDPR / health data), public sector, regulated tech. We are not lawyers but we draft artifacts that your legal team can stamp. **Q: How does this differ from buying a generic AI policy template?** Generic templates are written for the abstract case and break on first contact with real procurement questions. We tailor to your tooling, your industry and your specific procurement reality. Output is defensible at audit, not just a checkbox. **Q: Can you implement evaluation tooling, not just write the policy?** Yes. The evaluation cadence playbook can be paired with tooling implementation under LLM Observability (eval pipelines, automated scoring) or with a recurring Independent AI Code Audit. **Q: How long until artifacts are signed off?** Typical engagement is 4-6 weeks from kickoff to published, signed-off artifacts. The bottleneck is usually internal review cycles, not drafting. ### Related - https://23minds.com/services/evaluate-audit-secure/security-review - https://23minds.com/services/operate-measure-maintain/llm-observability --- ## EU AI Act Technical Compliance - Train & Adopt **URL:** https://23minds.com/services/train-adopt-govern/eu-ai-act-compliance **Service type:** EU AI Act technical compliance assessment and documentation **Anchor:** Train, Adopt & Govern (Train & Adopt) > The engineering half of AI Act compliance: 23Minds inventories and classifies your AI systems, writes the technical documentation, produces the testing evidence and turns logging, traceability and human oversight into architecture your team actually runs. ### Summary 23Minds delivers the technical side of EU AI Act compliance for organizations that build, buy or deploy AI systems. The service inventories every AI system in use, classifies each one against the Act's risk tiers, writes the technical documentation the current obligations require, and produces adversarial-testing evidence that stands up to an audit. Logging, traceability and human oversight count as architectural requirements with named owners and working implementations, not as promises in a policy document. The engagement ends with a gap analysis and a costed remediation roadmap, plus an AI literacy plan that feeds directly into training for the people who operate these systems. Engineers, not lawyers, do this work: the team builds the technical evidence and works alongside your legal counsel or a partner law firm, which owns the legal interpretation and sign-off. ### Who it's for - Product startups whose AI feature was just classified as high-risk by a customer's procurement questionnaire - Software houses and system integrators who must hand clients AI Act documentation for what they deliver - Corporate and public-sector teams deploying purchased AI systems and carrying deployer obligations they did not write - Regulated organizations in finance, health, HR, education and critical infrastructure with audit deadlines in front of them - Compliance leads, CISOs, CTOs and heads of legal who need technical artifacts their counsel can sign ### Problems we solve - Nobody can produce a list of the AI systems your organization actually runs, let alone their risk classification - A client, tender or auditor asked for AI Act technical documentation and there is nothing written down - Your systems log business events but not the model decisions, inputs and versions that traceability requires - Human oversight exists on a slide but no interface, role or escalation path implements it in production - Legal counsel gave you the obligations and the engineering team has no idea what to build in response ### What you get - AI system inventory with owners, purpose, data flows, model and vendor per system - Risk classification per system against the Act's tiers, with the reasoning written out for audit and legal review - Technical documentation pack per in-scope system, structured to the Act's requirements - Logging, traceability and human oversight specification, with the architectural changes needed to meet it - Evaluation evidence file drawn from quality evaluation and code security review of the system, where required - Gap analysis and costed remediation roadmap, plus an AI literacy plan mapped to roles ### How we work 1. **1. Inventory and discovery** (Week 1-2): Find every AI system in use: built, bought and embedded in third-party tools. Capture purpose, users, data, model, vendor and owner for each. 2. **2. Risk classification** (Week 2-3): Classify each system against the Act's risk tiers and your role for it, provider or deployer. Document the reasoning so legal counsel can confirm or challenge it. 3. **3. Gap analysis** (Week 3-4): Compare current state against the obligations that apply: documentation, data governance, logging, traceability, human oversight, accuracy and robustness, testing evidence, AI literacy. 4. **4. Documentation and evidence** (In a project, weeks 4-7): Write the technical documentation pack, specify the logging and oversight architecture, and assemble the testing evidence file. Review with your legal counsel or our legal partner. 5. **5. Remediation roadmap and handover** (In a project, weeks 7-8, then quarterly review): Deliver the costed roadmap with owners and sequencing, brief leadership, and set the review cadence that keeps documentation current as systems change. ### FAQ **Q: Is this legal advice?** No, and we say so plainly. We are an engineering team. We produce the technical artifacts the Act requires - inventory, classification reasoning, documentation, logging and oversight design, testing evidence - and your legal counsel owns the interpretation and the sign-off. Where you have no counsel for this, we bring a legal partner into the engagement and split the work explicitly. **Q: The obligations keep moving. How do you handle that?** We work against the obligations in force at the time of the engagement and we date every classification and every document. Where the interpretation is genuinely open we flag it as a decision for your counsel rather than guessing, and we always recommend legal confirmation before you rely on a classification externally. The quarterly review keeps the pack current as systems and guidance change. **Q: How long does it take and how is it priced?** A typical engagement runs 6-8 weeks from kickoff to a delivered documentation pack and roadmap. Pricing is fixed per engagement, scoped after a first call, and driven by the number of AI systems in scope and how many of them land in the high-risk tier. Inventory and classification alone can be bought as a smaller first step. **Q: What do you need from us to start?** Access to the people who own each AI system, existing architecture and data-flow documentation, vendor contracts and DPAs for purchased AI, and any classification or legal analysis already done. We run structured interviews to fill the gaps - most organizations discover during this step that the real inventory is larger than the one on file. **Q: We only use AI systems built by vendors. Does this still apply?** Yes. Deploying an AI system carries its own obligations, separate from those of the organization that built it. We assess what your vendors actually give you, identify what is missing from their documentation, and write the deployer-side artifacts: oversight design, logging, instructions for use, and the questions to put to the vendor before renewal. **Q: How does this relate to testing and evaluation of the system?** Testing evidence is one of the technical artifacts that supports compliance for higher-risk systems. LLM Evaluation produces evaluation results and a scored test set; Security Review covers the code and the application layer. Both hand over findings in a form that drops straight into the documentation pack. You can buy any of them on its own; running them together removes duplicated discovery and produces one consistent evidence trail. **Q: What about the AI literacy obligation?** It is a real obligation and it is also the easiest one to close. We map roles to the level of AI understanding each needs, then feed that into a training plan. Our training programs deliver it, and the completion records become part of your compliance evidence. **Q: Remote or on-site, and can you work inside our environment?** Remote under NDA by default. Interviews and workshops run on-site where that gets faster answers, at the same price, and we can work entirely inside your own tooling and document systems when material cannot leave the organization. ### Related - https://23minds.com/services/train-adopt-govern/ai-governance-basics - https://23minds.com/services/evaluate-audit-secure/ai-quality-evaluation - https://23minds.com/services/train-adopt-govern/ai-training-programs --- # Evaluate, Audit & Secure (anchor 02) **URL:** https://23minds.com/services/evaluate-audit-secure **Highlight:** Evaluation of AI-written code > Independent evaluation of AI-generated code, security review and production-readiness checks - so teams ship faster with AI and know what is safe to release. ### Summary 23Minds provides independent evaluation and assurance for AI-generated code and AI-assisted engineering outputs. The evaluation practices audit code produced by coding assistants for correctness, security and maintainability; run security reviews of AI-touched systems; design test coverage strategies for AI-assisted projects; and certify production readiness before release. Studies of AI-generated code show what to look for: in Veracode's 2026 test of more than 100 models, the secure implementation was chosen in 56% of cases on average, and in a 2026 study of 6,299 GitHub repositories 22.7% of the issues introduced by AI-authored commits were still in the latest version. Security findings are assigned to OWASP Top 10 (2025 edition) categories and, for AI features, to the OWASP Top 10 for LLM Applications. The company's quality management system is certified by DNV to ISO 9001:2015 (certificate no. 10000439701-MSC-RvA-POL, valid until 3 March 2027). ### Who it's for - Engineering leaders shipping AI-assisted code who need an external assurance signal - CTOs of regulated companies (fintech, health, public sector) under scrutiny over AI in code - Security teams responsible for products built with AI coding assistants - Vendor management teams evaluating AI-touched deliverables from outside contractors ### Problems we solve - AI-generated code lands in PRs faster than humans can review it thoroughly - Compliance asks for proof that AI-assisted code meets the same bar as human-written code - Test coverage drops because AI tools generate plausible-looking but unverified code - Security teams cannot tell where AI contributions are concentrated in the codebase ### Practices under this anchor - Independent AI Code Audit - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - Security Review - https://23minds.com/services/evaluate-audit-secure/security-review - Tests for AI-Assisted Code - https://23minds.com/services/evaluate-audit-secure/test-coverage - Production Readiness - https://23minds.com/services/evaluate-audit-secure/production-readiness - LLM Evaluation - https://23minds.com/services/evaluate-audit-secure/ai-quality-evaluation ### FAQ **Q: What does an Independent AI Code Audit engagement look like?** Fixed fee, agreed once the scope is clear. We take a repo or set of PRs, sample AI-touched code, run our evaluation rubric (correctness, security, maintainability, test fitness), produce a written report with prioritized findings, and brief the team on the top issues. The package for one repository takes up to four weeks from scope approval. **Q: Do you replace human code review?** No. The audit adds a periodic, independent report with findings and recommended fixes to your team's own reviews. It can be booked on a cycle, for example once a quarter, alongside your own process. **Q: What tools do you cover?** Any LLM-based coding assistant: Cursor, Claude Code, Cody, Copilot, Windsurf, Aider. The output is the artifact we evaluate, not the tool. In Stack Overflow's 2025 survey, 84% of the developers who answered that question used or planned to use AI tools, and 46% of those answering the trust question distrusted the accuracy of the output. **Q: Can you deliver under NDA for regulated industries?** Yes. We work under standard NDA, can operate on isolated infrastructure, and can deliver in-person at client offices for highly sensitive engagements. In regulated industries we agree the list of requirements to check before the start and record the result in the report. **Q: What does the report look like?** A structured PDF + prioritized issue tracker entries (or Linear, Jira, GitHub Issues). Each finding includes severity, reproduction, recommended fix and links to the offending code. We follow up on remediation if requested. **Q: Which regulations make an external assessment of code relevant?** The Cyber Resilience Act (Regulation (EU) 2024/2847) has required manufacturers of products with digital elements to report actively exploited vulnerabilities since 11 September 2026, with an early warning within 24 hours, and applies in full from 11 December 2027. For high-risk AI systems, Article 15 of the AI Act (Regulation (EU) 2024/1689) sets requirements for accuracy, robustness and cybersecurity; after Regulation (EU) 2026/1744 they apply from 2 December 2027 for systems listed in Annex III and from 2 August 2028 for AI in regulated products. Whether a system is high-risk depends on its use; writing the code with an assistant does not decide it. An audit report does not make a product compliant: it documents what was checked, when and by whom. --- ## Independent AI Code Audit - Evaluate & Secure **URL:** https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation **Service type:** Software code audit and assurance **Anchor:** Evaluate, Audit & Secure (Evaluate & Secure) > Independent audit of AI-generated and AI-assisted code - graded for correctness, security, maintainability and test fitness against an engineering rubric you read in full before you sign. ### Summary 23Minds provides an independent AI code audit for engineering teams shipping AI-assisted code. The audit samples AI-touched files or PRs from your repository, evaluates each finding against a four-dimension rubric (correctness, security, maintainability, test fitness), produces a written report with severity-ranked findings, and ends with a briefing for the team on the top issues. The rubric is public: every dimension has a written definition, named sub-criteria and a 0-4 scale, so you see how the code is graded before you buy and can apply the same standard yourself between audits. ISO 9001:2015 quality assurance backing. Fixed fee agreed once the scope is clear, up to four weeks per repository. Studies of AI-generated code point to problems worth looking for: 29.5% of the Python snippets written by coding assistants in public GitHub projects had security weaknesses (Fu et al., ACM TOSEM 2025), and 22.7% of the issues introduced by AI-authored commits in 6,299 repositories were still in the latest version (Liu et al., 2026). ### Who it's for - VPs of engineering and CTOs needing an external assurance signal on AI-assisted code - CISOs whose teams ship AI-generated code into regulated production systems - Vendor management teams reviewing AI-touched deliverables from contractors - Compliance officers required to demonstrate code review depth at audit ### Problems we solve - AI-generated code lands faster than humans can review it thoroughly - Compliance asks for proof AI-assisted code meets the same bar as human code - Audit findings arrive as opinions with no stated method, so nobody can repeat or contest them - Test coverage drops because AI tools generate plausible-looking but unverified code - Security teams cannot tell where AI contributions concentrate in the codebase ### What you get - Written audit report (structured PDF, ~30-60 pages depending on scope) - Per-dimension scorecard on the published 0-4 scale, with the anchor behind each score and the weighting agreed for your context - Severity-ranked finding list (Critical / High / Medium / Low) with reproductions - Per-finding recommended fix with code snippets and links to offending lines - Prioritized issue-tracker entries (Linear, Jira, GitHub Issues - your choice) - Executive briefing presentation with top issues and remediation roadmap ### How we work 1. **1. Scope + sampling** (Week 1): Define audit scope: which repos, which PR window, which tooling produced the code. Walk through the published rubric and agree the weighting for your context. 2. **2. Evaluation** (Week 2-3): Run the four-dimension rubric across sampled code. Reproduce findings, score each dimension on the published scale, write up severity and recommended fix. 3. **3. Report + briefing** (Week 3-4): Deliver the written report, walk leadership and engineering through the top findings, file prioritized tracker entries. 4. **4. Remediation follow-up (optional)** (Week +4-8): Re-review remediated findings 4-8 weeks later. Issue a remediation certificate if standard met. ### FAQ **Q: What does an audit cost?** The entry package for one repository has a from-price, listed on this page: the effort depends on the size and complexity of the code, and once the scope is agreed on the intro conversation the price is fixed, with no hidden costs. A larger scope - several repositories, a whole platform, quality gates in CI - is priced after that conversation, once the scope is clear. **Q: What is your evaluation rubric?** Four dimensions, each published with its own definition. Correctness: does the code do what the ticket and the tests say, including edge cases and error paths. Security: does it introduce vulnerabilities, unsafe defaults, weak secret handling or dependency risk. Maintainability: will the next engineer understand, locate and change it without reading the whole system. Test fitness: is coverage real - do the tests fail when behavior breaks - or theatrical. Each dimension carries named sub-criteria weighted to your codebase. **Q: How is each dimension scored?** On a published 0-4 scale with fixed anchors: 0 blocking defect, release must stop; 1 major gaps requiring rework before release; 2 works but with material findings and debt to schedule; 3 meets the bar with minor findings only; 4 no findings against that dimension. Every score in the report names the anchor it was assigned on, so you can contest an individual rating rather than the report as a whole. The full rubric, sub-criteria and scale are published on this page, do not change between engagements, and clients apply them to their own PRs between audits. **Q: Can you deliver under NDA for regulated industries?** Yes. Standard NDA, can operate on isolated infrastructure, can deliver in-person at client offices for highly sensitive engagements. Industry-specific frameworks (fintech KNF/DORA, healthcare GDPR/HIPAA-adjacent) are accommodated. **Q: Do you compete with my internal code review?** No. We are an external assurance signal - periodic, independent, deeper than day-to-day review. You can book it on a cycle, for example once a quarter, alongside your own process. **Q: Can you re-audit after remediation?** Yes. Remediation re-audits are scoped at half the original engagement fee and produce a remediation certificate confirming findings closed. Useful for board reporting or external audit prep. **Q: What do published studies say about the quality of AI-generated code?** The results depend on the problem studied. In real GitHub projects, 29.5% of the Python and 24.2% of the JavaScript snippets written by coding assistants had security weaknesses (Fu et al., ACM TOSEM 2025, 733 snippets). Across 576,000 code samples from 16 models, 19.7% of the 2.23 million package references pointed to packages that do not exist (Spracklen et al., USENIX Security 2025). A controlled experiment with 151 participants found no systematic maintainability difference between code written with an AI assistant and code written without one (Borg et al., ICSME 2025). The audit checks security, dependencies, maintainability and tests in an agreed sample of your code. ### Related - https://23minds.com/services/evaluate-audit-secure/security-review - https://23minds.com/services/evaluate-audit-secure/production-readiness - https://23minds.com/services/operate-measure-maintain/llm-observability --- ## Security Review - Evaluate & Secure **URL:** https://23minds.com/services/evaluate-audit-secure/security-review **Service type:** Application security code review **Anchor:** Evaluate, Audit & Secure (Evaluate & Secure) > A security-focused review of the code your team wrote with AI coding assistants - injection flaws, unsafe defaults, secrets handling, generated authorization logic - plus the application-level surface your AI features introduced, delivered as reproducible findings with fixes in the code. ### Summary 23Minds reviews the security of code produced with AI coding assistants and of the AI features that code adds to a product. The review covers the AI-touched parts of your repository: injection flaws, unsafe defaults, secrets handling, dependency choices the assistant made, authorization logic it generated and error handling that leaks internals. It then moves to the application-level AI surface: how the app builds prompts, what it sends to and trusts back from an LLM API, how user input reaches a prompt, what an in-app agent is permitted to call, and how model output is handled before it reaches a user, a browser or a database. Every finding ships with a reproduction and a concrete fix in your code, plus the review rules your team applies afterwards so the same class of issue stops at code review. This is a code-level engagement: infrastructure, cloud and organizational security are out of scope by design. ### Who it's for - Product teams that adopted an AI coding assistant and are now shipping code faster than anyone reviews it for security - Software houses and agencies delivering AI-assisted code whose clients started asking for an independent security opinion on it - Companies that added an LLM feature (chat, summarization, an in-app agent) to an existing product and never reviewed what it exposed - Engineering leads, CTOs of product teams and tech leads who need the findings in the repository, not in a governance document ### Problems we solve - The assistant wrote query building, file handling and request parsing at speed, and nobody checked those paths for injection - Generated code carries the framework defaults the model happened to know: permissive CORS, disabled verification, debug error output in production - Secrets and tokens are handled the way the assistant demonstrated them - in code, in logs, in client bundles - Authorization checks were generated per endpoint and no one has verified they are consistent, or present at all - User input reaches a prompt unfiltered and model output goes straight into HTML, a shell call or a database write - An in-app agent holds tool access and credentials far wider than the task it actually performs ### What you get - Severity-ranked finding list (Critical / High / Medium / Low), each with a reproduction and the exact file and lines - A concrete fix per finding: a patch, a diff or a worked example your engineers can apply directly - Review of the AI feature surface: prompt construction, trust boundaries around the LLM API, output handling, agent tool and permission scope - Secrets and dependency findings for the AI-touched code, including packages the assistant introduced - A short set of security review rules for the team - what to look for in AI-generated PRs, as a checklist and as linter or CI rules where they can be automated - Working session with the engineering team on the top findings and how each one got written ### How we work 1. **1. Scope + code walkthrough** (Week 1): Agree which repositories and which AI-touched code are in scope, which assistant produced it, and where the AI features sit. Walk the codebase with a senior engineer from your side. 2. **2. Code-level security review** (Week 1-2): Read the AI-touched code for injection flaws, unsafe defaults, secrets handling, generated authorization logic, dependency choices and leaking error handling. Reproduce what we find. 3. **3. AI feature surface review** (Week 2-3): Trace how user input reaches a prompt, what the app sends to and trusts back from the LLM API, what an in-app agent is permitted to call, and how output is handled before it reaches a user or a data store. 4. **4. Report, fixes + review rules** (Week 3): Deliver the finding list with fixes, walk the engineering team through the top issues, and hand over the review rules and CI checks that catch the same classes in future PRs. ### FAQ **Q: How is this different from the Independent AI Code Audit?** The Independent AI Code Audit grades AI-assisted code on four dimensions - correctness, security, maintainability, test fitness - and gives you an overall assurance signal. Security Review takes only the security dimension and goes far deeper: we chase each issue to a working reproduction and a fix in the code, and we also review the AI feature surface, which the evaluation rubric only samples. Teams that want a single broad picture buy the audit; teams that already know security is the concern buy this. **Q: What do you explicitly not cover?** We do not do infrastructure, cloud or network security, penetration testing of live systems, offensive red teaming of deployed AI, SOC 2 or ISO 27001 audit programmes, or organizational security governance. We also do not assess your LLM vendor or model supply chain. We review code and the application-level surface that code creates. If you need any of the above, bring in a specialist for it - we are happy to hand over our findings so their work starts from something concrete. **Q: What access do you need?** Read access to the repositories in scope, the PR history for the AI-touched period, and a running instance in a non-production environment so we can reproduce findings. No production access, no customer data. A senior engineer from your side for a walkthrough at the start and a review of the findings at the end. Everything runs under NDA. **Q: How long does it take?** Most engagements run 2-3 weeks from scoping to report. A single service or a well-bounded AI feature can be done in a week; a large multi-repository codebase is scoped as several passes rather than one long review. Fixed fee, agreed once the scope is clear. **Q: Do you work remotely or on-site?** Remotely by default, under NDA, on your repository access. On-site delivery in Poland is available where a client's policy requires the code never leaves their network, at the same fee. **Q: What does the team get afterwards?** The finding list with fixes, the review rules as a checklist, and whatever we could turn into linter or CI checks. The point is that the next PR written with an assistant gets caught by your own review, not by us. Teams typically bring us back after a few months for a shorter re-review rather than a repeat of the full engagement. **Q: Which languages and stacks do you cover?** TypeScript and JavaScript, Python, Go, Ruby, Java and Kotlin, and the common web frameworks around them. Mobile and embedded are out of scope for this practice. Tell us the stack on the intro call and we will say plainly whether we are the right team for it. **Q: Do we need to have shipped an AI feature to buy this?** No. Plenty of engagements cover an ordinary product where the only AI involved is the assistant that helped write it. If the product has no LLM feature, we drop phase 3 and put the time into the code review instead. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/evaluate-audit-secure/production-readiness --- ## Tests for AI-Assisted Code - Evaluate & Secure **URL:** https://23minds.com/services/evaluate-audit-secure/test-coverage **Service type:** Software quality and testing consulting **Anchor:** Evaluate, Audit & Secure (Evaluate & Secure) > Test strategy and implementation for AI-assisted projects - covering what to test (and what AI tools cannot test for you), what to mock, what to skip, and how to keep regressions in check as the AI keeps generating code. ### Summary 23Minds designs and implements test coverage strategies for engineering teams shipping AI-assisted code. AI coding tools generate tests that look thorough but often miss regressions and prop-up coverage metrics without protecting behavior. The service audits current tests, designs a coverage strategy aligned to your product risk (what must never break vs what can fail and be fixed forward), implements the critical-path tests AI cannot generate well, and sets up the CI signals that catch real regressions early. ### Who it's for - Engineering managers whose AI-assisted code is shipping faster than tests can keep up - Tech leads watching test coverage metrics rise while regressions rise too - CTOs trying to scale a small team using AI without breaking quality - QA leads adjusting their strategy for AI-generated code ### Problems we solve - AI generates tests that pass but do not protect business-critical behavior - Coverage metrics rise but customer-reported regressions also rise - Mocks proliferate as AI fills in gaps; the test suite tests itself, not the system - Critical-path integration tests are too tedious for AI to generate well; nobody writes them ### What you get - Audit of current test suite - what protects behavior vs what just inflates metrics - Risk-aligned test strategy document (what to test, what to mock, what to skip) - Implementation of critical-path tests AI tools struggle to generate - CI configuration for failure-mode signals (flake detection, regression alerts) - Playbook for team: prompt patterns for generating good tests with AI ### How we work 1. **1. Test audit** (Week 1): Sample existing tests across modules. Score each for true behavior protection vs metric padding. Identify gaps in critical paths. 2. **2. Strategy design** (Week 1-2): Map product risk to test strategy. Decide unit/integration/e2e mix. Pick what to mock vs run for real. 3. **3. Implementation** (Week 2-3): Write the critical-path tests AI tools miss. Set up CI signals. Document the prompt patterns for AI-generated tests. 4. **4. Team handover** (Week 3): Walk the team through the strategy. Pair on writing new tests using the playbook. Establish a review cadence. ### FAQ **Q: Why is AI bad at writing certain tests?** AI is great at unit tests that exercise visible function signatures, less good at integration tests that depend on system state, and weak at end-to-end tests where the cost of correct fixture setup exceeds what fits in context. The result is a test suite skewed toward easy wins, weak on real risk. **Q: Will you raise our coverage number?** We optimize for behavior protection, not raw coverage percentage. Most clients see coverage go down slightly (we remove tests that did not protect anything) and customer-reported regression rate drop more. **Q: Can you work with our existing CI?** Yes. GitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite - we work with what you have. We do not introduce new CI tools without a strong reason. **Q: What languages do you cover?** TypeScript / JavaScript, Python, Go, Ruby, Java/Kotlin. Mobile (Swift, Kotlin) and embedded are out of scope for this practice. **Q: How does this fit with the Independent AI Code Audit?** The Independent AI Code Audit checks existing code for correctness; this practice builds the tests that catch new regressions before they reach production. Most clients buy them as a pair. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/evaluate-audit-secure/production-readiness - https://23minds.com/services/build-automate-modernize/ai-powered-custom-development --- ## Production Readiness - Evaluate & Secure **URL:** https://23minds.com/services/evaluate-audit-secure/production-readiness **Service type:** Production readiness consulting **Anchor:** Evaluate, Audit & Secure (Evaluate & Secure) > Pre-release production readiness review for AI-touched systems - observability, runbooks, rollback paths and on-call signals checked against a structured rubric before the system goes live. ### Summary 23Minds runs production readiness reviews for AI-touched systems before they ship to customers. The review scores the system against a structured rubric - observability and tracing coverage, runbook quality, rollback paths, on-call alerting, capacity headroom, cost monitoring, dependency failure modes - and ends in a written certification with remediation requirements. The output is what SRE and platform teams need to sign off, and what leadership needs to defend the release at the post-mortem if something goes wrong. ### Who it's for - VPs of engineering signing off the launch of a new AI feature - Heads of SRE/platform asked to take an AI system on call - CTOs of growth-stage companies launching their first LLM-backed product - PMs whose launch depends on engineering and SRE both saying yes ### Problems we solve - AI features launch with no observability - debugging in production is guesswork - Runbooks for the new system are missing or untested - Rollback path was never exercised; production fires turn into multi-hour outages - Cost monitoring is missing; the first month's LLM bill is a shock ### What you get - Production readiness scorecard (10-15 dimensions, scored Pass / Partial / Fail) - Written certification statement with remediation requirements (if needed) - Runbook templates for the new system, tested with the on-call team - Rollback procedure documentation, exercised against a staging dry-run - Cost and capacity monitoring configuration recommendations ### How we work 1. **1. System review** (Week 1): Review architecture, observability stack, runbooks, on-call procedures, capacity plan, cost monitoring setup. 2. **2. Hands-on validation** (Week 2): Test rollback path in staging. Exercise runbooks with on-call team. Trigger test alerts to verify they fire correctly. 3. **3. Scoring + remediation list** (Week 2-3): Score against rubric. Write remediation requirements with priorities. Draft certification statement. 4. **4. Re-review (if remediation needed)** (Week +1-2): Re-check remediated dimensions. Issue final certification. ### FAQ **Q: Can you certify a system in 2 weeks?** Yes for systems with reasonable observability already in place. Systems missing fundamentals (no tracing, no runbooks) often need a 4-6 week remediation window before certification. **Q: What does the rubric cover?** Observability coverage, tracing depth, runbook quality, rollback procedure, on-call alerting, capacity headroom, cost monitoring, dependency failure modes, security baseline, AI-specific risk (prompt injection, model drift), and incident response readiness. **Q: Do you write the runbooks for us?** We provide templates and review what the team writes. We do not write runbooks the team has not validated - runbooks the on-call has not exercised do not protect anyone. **Q: Can you certify continuously, not just at launch?** Yes. Quarterly re-certification is a common retainer pattern. Useful when AI features evolve fast or as a board-level signal for production-critical systems. **Q: How does this differ from a security audit?** Security audit asks 'can attackers break this'. Production Readiness asks 'will this stay up under load, and can the team fix it fast when it breaks'. Most launches need both before going live. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/evaluate-audit-secure/security-review - https://23minds.com/services/operate-measure-maintain/llm-observability --- ## LLM Evaluation - Evaluate & Secure **URL:** https://23minds.com/services/evaluate-audit-secure/ai-quality-evaluation **Service type:** AI output and process quality evaluation **Anchor:** Evaluate, Audit & Secure (Evaluate & Secure) > Independent evaluation of the AI already running in your product or your back office - answer quality, retrieval grounding, agent task success and whether the AI step genuinely shortens the process - scored against a rubric that stays with you. ### Summary 23Minds evaluates the quality of AI solutions that are already live: LLM features in a product, retrieval-based (RAG) answers, and agentic workflows that run without a person watching. The engagement builds an evaluation set from your real cases, agrees a scoring rubric with the people who own the business outcome, scores every case, and delivers a written report with a measured baseline, the failure patterns behind the score and a recommended fix per pattern. The unit of work is one evaluation - one test case scored against the rubric - so the scope and the invoice describe the same thing. The evaluation set and the rubric stay with you and get wired into CI as a quality gate that catches regression the next time a model, prompt or vendor changes. The service is tool-neutral: it runs on the evaluation stack you already have or helps you choose one, and at high volume it shows where self-hosting costs less than SaaS. ### Who it's for - Product teams that shipped an LLM feature and have no way to tell whether the answers are actually good - Companies running an internal AI assistant with flat adoption and no measure of whether it helps anyone - Teams about to change model, prompt framework or vendor and afraid of a silent regression - Operations and shared-service leads who put an AI step into a process and need to prove it shortened the process instead of moving the work - Heads of engineering, data and support who started with a free evaluation tool, got traces flowing and stalled on the test set ### Problems we solve - The LLM feature is live and the only quality signal is a complaint or a support ticket - RAG answers read fluently, but nobody has verified they are grounded in the right source document - Agentic workflows report success while a human quietly finishes the job, and nobody counts how often - A prompt or model change ships and users discover the regression before the team does - The team adopted a free evaluation tool and stalled on two things: building the test set and agreeing what 'good' means ### What you get - Evaluation set built from your real traffic and edge cases, in your tooling, owned by you after the engagement - Scoring rubric with weighted dimensions (correctness, grounding, task success, format and tone, cost and latency) agreed with the business owner, not just with engineering - Baseline scorecard: every case scored, results broken down per dimension, per user journey and per model or prompt version - Failure-pattern report with reproductions, root cause and a recommended fix for each pattern - CI quality gate: the evaluation set running as a blocking check on prompt, model, retrieval and vendor changes - Process effectiveness read-out showing where the AI step shortens the process and where it moves work to a human, plus a tooling recommendation with a self-hosting versus SaaS cost comparison at your volume ### How we work 1. **1. Scope + rubric** (Week 1): Agree what 'good' means for this solution with the people who own the outcome. Define the quality dimensions, their weights and the pass threshold. Fix the number of evaluations in scope. 2. **2. Evaluation set build** (Week 1-2): Assemble test cases from real traffic, known failures and the edge cases nobody tests. Add expected answers or grading criteria per case. Wire the set into your evaluation tooling or into one we help you pick. 3. **3. Scoring + analysis** (Week 2-3): Score every case against the rubric using automated grading, model grading and human review where the rubric needs judgment. Group failures into patterns and trace each pattern to its cause: retrieval, prompt, model choice, tool wiring or process design. 4. **4. Report + handover** (Week 3-4): Deliver the baseline scorecard and failure-pattern report, walk the product and engineering owners through it, and hand over the evaluation set and rubric wired into CI as a quality gate your team can run without us. 5. **5. Continuous evaluation (optional)** (Ongoing): Retainer: we maintain and extend the evaluation set, re-run it after every model, prompt or vendor change, and report the regression before your users find it. ### FAQ **Q: What exactly is included, and how do you price it?** The unit of work is one evaluation: one test case scored against the agreed rubric. We fix the number of evaluations, the rubric and the reporting in the scope, so you can see what you are paying for. Fixed fee per engagement, scoped to the number of evaluations and the number of AI surfaces in scope. We share a tight range on the intro call once scope is clear. **Q: How long does it take and what do you need from us?** Three to four weeks from kick-off to handover. From you we need one person who owns the business outcome to agree the rubric, one engineer for access and tooling, a sample of real traffic or logs, and any known failure cases you have already collected. The rubric workshop and the handover session take about half a day each; the rest runs on our side. **Q: How is this different from the Independent AI Code Audit?** The Independent AI Code Audit covers the code: correctness, security, maintainability and test fitness of what your team and your AI tools wrote. LLM Evaluation covers the behaviour of the deployed solution: whether the answers are right and grounded, whether the agent finishes the task, whether the process actually got shorter. Perfectly clean code can still produce a system that answers badly, and the reverse is also true. Teams frequently buy both, usually in that order. **Q: Do you need access to our production data?** Not necessarily. We can work on anonymised or synthetic cases derived from your real ones, and many engagements run that way for regulated clients. Where production access is granted, we work under NDA, on your infrastructure, with the data staying in your environment. Standard NDA, and we can operate on isolated infrastructure if the engagement requires it. **Q: Which evaluation tools do you work with?** We are tool-neutral and work on what you already run: Braintrust, Langfuse, LangSmith, Confident AI, Promptfoo, Arize Phoenix, W&B Weave, or a plain test harness in your own repository. If nothing is in place we help you choose, and at high evaluation volume we show you where self-hosting an open-source platform costs less than SaaS. The evaluation set is written so it can move between tools, because tying your quality baseline to a single vendor is a risk in a market that keeps consolidating. **Q: We already tried a free evaluation tool. What do you add?** Every evaluation platform has a free tier, so most clients arrive having tried one. The tool is rarely where teams get stuck. They get stuck on the two things the tool does not give you: a test set that represents what users actually ask, and a written definition of 'good' that the business owner and the engineers both sign. We start exactly there, and the tool you already picked keeps running underneath. **Q: Can you evaluate agentic workflows, not just single answers?** Yes, and that is usually where the interesting numbers are. We score task success rate (did the agent complete the job end to end), human takeover rate (how often a person silently finishes it), step-level failures across sessions, turns, tool calls and subagents, and process effect: how much time the AI step removes from the process versus how much it moves to someone else. **Q: What happens after the engagement, and who maintains the evaluation set?** The evaluation set, the rubric and the CI gate are yours, in your repository and your tooling, and your team can run and extend them without us. If you would rather not own the maintenance, we run it as a continuous retainer: we keep the set current, re-run it after each model, prompt or vendor change, and report regression against your baseline. That retainer sits alongside LLM Observability, which watches the same quality signals in live traffic. ### Related - https://23minds.com/services/evaluate-audit-secure/ai-code-evaluation - https://23minds.com/services/operate-measure-maintain/llm-observability - https://23minds.com/services/evaluate-audit-secure/production-readiness --- # Build, Automate & Modernize (anchor 03) **URL:** https://23minds.com/services/build-automate-modernize **Highlight:** Production systems built with AI > Custom software development with AI, process automation and legacy modernization - engineered for production, not for demo. ### Summary 23Minds builds, automates and modernizes systems with AI at the centre of the engineering process. Custom development ships production applications, agentic backends and AI-augmented internal tools to engineering teams that need product velocity. Process automation leaves the client with a documented procedure and a named owner, and legacy modernization applies AI-assisted refactoring where it unlocks otherwise prohibitive change. Every engagement runs under the company's ISO 9001:2015 quality management system, certified by DNV (certificate no. 10000439701-MSC-RvA-POL, valid until 3 March 2027). ### Who it's for - Product engineering teams shipping AI-native or AI-augmented products - Operations and finance leaders whose process has to run the same way after the one person who knows it is gone - CTOs sitting on legacy systems that block roadmap progress - Founders prototyping agentic backends and need senior engineering judgment ### Problems we solve - AI prototypes built by the team do not survive the move to production - A back-office process runs by hand and from memory, and nobody can write down what happens on an exception - A legacy system blocks the product roadmap but a full rewrite is not affordable - Agentic workflows look promising in demos but no one knows what production looks like ### Practices under this anchor - Custom Software Development with AI - https://23minds.com/services/build-automate-modernize/ai-powered-custom-development - Process Automation - https://23minds.com/services/build-automate-modernize/process-automation - Legacy Modernization - https://23minds.com/services/build-automate-modernize/legacy-modernization ### FAQ **Q: How is Custom Software Development with AI different from regular custom development?** Our engineering process puts AI to work at every step: AI-assisted coding, AI-driven test generation, AI-augmented code review. The deliverable is the same: a production application. The velocity and the cost structure are different. **Q: Do you build agents end-to-end?** Yes. We design the agent architecture (single-shot, multi-step, multi-agent), build the supporting infrastructure (memory, retrieval, tool calls, observability), integrate with your existing systems, and ship to production with on-call runbooks. **Q: What kinds of processes do you automate?** Processes that run by hand today and have to survive an audit tomorrow: invoice intake, order handling, onboarding, compliance checks, reporting. We build on tools your team can operate (UiPath, Power Automate, n8n) and hand the automation over as a documented procedure with an owner, a version history and a review cycle. Robotic automation of business processes is within the scope of our ISO 9001 certificate. **Q: Can you modernize a legacy system in place, without a full rewrite?** Often yes. We assess the system, identify the strangler-fig boundaries, and replace components incrementally using AI-assisted refactoring. The roadmap blocker comes off without a multi-quarter rewrite. **Q: What stacks do you work in?** TypeScript / Node / Next.js, Python / FastAPI, Go for backend; React, Vue for frontend; Postgres, ClickHouse, Pinecone, pgvector for data; AWS, GCP, Vercel, Fly for infrastructure. Most LLM providers (OpenAI, Anthropic, Google, open-source via Bedrock or Together). **Q: Does AI make software delivery faster?** Measurements disagree, which is why we measure it on your project. In three field experiments with 4,867 developers at Microsoft, Accenture and a Fortune 100 company, developers using GitHub Copilot completed 26.08% more tasks (Cui et al., Management Science, 2026). In METR's randomised trial, 16 experienced open-source developers took 19% longer with AI tools while estimating they had been 20% faster (July 2025); a February 2026 follow-up could not confirm a speed-up, because its confidence interval included zero. DORA's 2024 report estimated that a 25% increase in AI adoption goes with a 7.2% drop in delivery stability, and the 2025 report, based on nearly 5,000 respondents, still linked wider AI use with lower stability and higher throughput. That is why each phase report gives the number of changes shipped to production and the number of defects found after merge over the same period. --- ## Custom Software Development with AI - Build & Modernize **URL:** https://23minds.com/services/build-automate-modernize/ai-powered-custom-development **Service type:** Custom software development **Anchor:** Build, Automate & Modernize (Build & Modernize) > End-to-end product engineering with AI at the centre of the process - production applications, agentic backends and AI-augmented internal tools built on a staged pipeline where every change passes automated gates and two independent code reviews before production, and an engineer reads risky changes line by line. ### Summary 23Minds builds production software with AI at the centre of the engineering process. The practice delivers web applications, agentic backends, AI-augmented internal tools and AI-native products to teams that need senior engineering judgment at the velocity AI now enables. Every change moves through the same pipeline: ticket, spec, plan, implementation, automated gates (typecheck, lint, tests, build, a dependency and secrets check, two independent code reviews), PR with preview, line-by-line human review for risky changes, merge, verification in production. The pipeline accelerates delivery and holds stability, and the team measures both: throughput and defects found after merge. ISO 9001:2015 quality assurance backing. ### Who it's for - Product engineering teams shipping AI-native or AI-augmented products - Founders prototyping a new AI-first product who need senior engineering - Mid-stage companies replacing or extending a critical internal tool - Scale-ups whose product roadmap exceeds in-house engineering capacity ### Problems we solve - AI prototypes built by the team do not survive the move to production - A prompt-built prototype stalls at the demo: no tests, no review trail, no runbook, no owner in production - the delivered system has all four - In-house engineering is full; the roadmap keeps slipping - Agentic workflows demo well but the team has no production pattern for them - Custom development quotes from agencies do not account for AI-driven velocity ### What you get - Working production application (web, agentic backend, internal tool) - Source code with documentation, tests, deployment configs, runbooks - Delivery pipeline handed over with the code: CI gates, PR template, review checklist, preview environments - Infrastructure-as-code for production, staging, preview environments - Observability and on-call setup (tracing, alerts, runbooks) - Knowledge transfer to your team - pair sessions, walkthroughs, recorded handover ### How we work 1. **1. Intro call + scope** (Week 0-1): Intro call, problem definition, technical scoping, fixed-fee phase proposal. 2. **2. Ticket, spec, plan** (Per change): Every change starts as a ticket, becomes a written spec, then a plan. Gate: you approve scope and plan before a line of code is written. 3. **3. Implementation** (Per change): AI agents write the code and its unit tests under a senior engineer who sets the pattern, directs, corrects and rejects. Gate: every change in behaviour has a test that checks it, and without one the change does not move on. 4. **4. Automated gates** (Every commit): Typecheck, lint, tests, build and a dependency and secrets check run on every branch, then models from two different families review the diff independently. Gate: every critical or high finding is fixed before the change moves on, with the same threshold for AI-written and hand-written code. 5. **5. PR, preview + risk review** (Per change): Each PR gets a preview environment with the change running end to end, and both reviews are recorded in the PR. Gate: changes to migrations and data, authentication and permissions, payments or integrations with your systems are read line by line by an engineer before they ship. 6. **6. Merge + production verification** (Per release): After deploy we run smoke checks on the live address and read the logs from the first minutes. Gate: if the check finds a problem, we first restore service using the rollback plan agreed before the deploy, then fix; the change is done when it works in production and you have accepted it there. 7. **7. Hardening, launch + handover** (Last 2-4 weeks): Production readiness review, load testing, observability completeness, on-call training, then pair sessions and documented handover. Optional maintenance under AI Application Maintenance. ### FAQ **Q: How fast can you start?** From the intro call to the first sprint typically 2-3 weeks. Faster for urgent engagements (1 week) when scope is already clear and we have capacity. **Q: Does AI-driven velocity cost us stability?** That is the trade we refuse, and the reason the pipeline exists. We track delivery throughput and defects found after merge side by side, report both, and treat rising post-merge defects as a reason to tighten gates, not as the price of speed. Industry data shows the trade-off: DORA's 2024 report estimated that a 25% increase in AI adoption goes with a 7.2% drop in delivery stability, and the 2025 report, based on nearly 5,000 respondents, still found stability falling while throughput rose. Results on speed differ: developers using GitHub Copilot completed 26.08% more tasks in three field experiments with 4,867 developers (Cui et al., Management Science, 2026), while experienced open-source developers in METR's 2025 trial took 19% longer with AI tools. **Q: Fixed fee or time and materials?** Fixed fee per phase. The first phase is a PoC sprint when the scope has to be tested against your data; its package price is in the price list on this page. Where the scope is already clear, we start from the first build phase at a fixed price. Later phases are priced one at a time, on what the previous one taught us. **Q: What about IP ownership?** You own the code. We retain rights to reusable internal libraries and patterns we wrote before the engagement. Standard mutual NDA on the engagement itself. **Q: Will we work with the same engineers throughout?** Yes. Engagement teams are stable from kickoff to handover. We do not swap engineers mid-engagement unless you ask us to. **Q: Can you do AI engineering specifically, not just any custom dev?** Yes. Agentic backends (single-shot, multi-step, multi-agent), RAG systems, LLM-backed APIs, AI evaluation pipelines, embedding and vector search infrastructure. Systems with AI inside are handed over with an evaluation of answer quality as well. ### Related - https://23minds.com/services/build-automate-modernize/legacy-modernization - https://23minds.com/services/operate-measure-maintain/app-maintenance --- ## Process Automation - Build & Modernize **URL:** https://23minds.com/services/build-automate-modernize/process-automation **Service type:** Business process automation **Anchor:** Build, Automate & Modernize (Build & Modernize) > 23Minds automates a business process and leaves it in your organization as a written, versioned procedure with a named owner. Robotic automation of business processes is within the scope of the company's ISO 9001 certificate, so the same quality system covers the automation and the rest of its engineering work. ### Summary 23Minds automates business processes for operations, finance and back-office teams that need the automation to stay understandable, changeable and auditable after handover. Robotic automation of business processes in IT systems is within the scope of the company's ISO 9001:2015 certificate (DNV Business Assurance, no. 10000439701-MSC-RvA-POL), so every automation ships with what a quality system expects: a process description, a step-by-step procedure, exception handling, a named owner, a version history and a review cycle. The automation runs on tooling your team can operate (UiPath, Power Automate, n8n or plain scripts), with a language-model step behind a confidence threshold wherever a document, an email or a transcript has to be read. What stays with you is a procedure your team runs, changes and audits without 23Minds. ### Who it's for - Heads of operations whose process runs from one person's memory and has to run the same way when that person is away - Finance and administration leads whose process has to pass an audit: who changed what, when, and on whose approval - Quality managers in ISO 9001-certified organizations who need automations documented like any other procedure - Teams that inherited an automation from a vendor or a former colleague and nobody can say what it does ### Problems we solve - The process lives in one person's head and a spreadsheet; nobody can write down what happens when an exception comes in - An automation bought from a vendor runs as a black box: no documentation, no version history, nobody on your side who can change it - Your quality system requires a documented procedure and an owner for the process, and the bot has neither - Every change in a source system breaks the automation, and the fix is a call to someone who may not pick up - Half-built scripts and prompts run in production with no test, no log and no record of who approved the last change ### What you get - Process description as-is and to-be: steps, decisions, exception paths and the systems each step touches - Working automation in your environment, on tooling your team can operate (UiPath, Power Automate, n8n or plain scripts) - Procedure with a named owner, a change log, a version history and an approval record for every change - Exception handling with escalation to a named person, and a log that shows what the automation did and why - Handover and training for the owner and a deputy, plus a review cycle: what to check, how often, who signs - Optional: periodic reviews under AI Application Maintenance ### How we work 1. **1. Process mapping** (Week 1-2): We sit with the team that runs the process by hand and write down the as-is: steps, decisions, exceptions, systems. The to-be is agreed with the process owner. Gate: the owner signs the process description. 2. **2. Design + tool choice** (Week 2-3): Per step we choose the tool: RPA, a script, or a model-based step where something has to be read. We design the exception paths and the log. Gate: a written design, including the steps that stay manual and why. 3. **3. Build + test** (In a project, weeks 3-6): We build in your environment and test against real cases, exceptions included. Every change carries a version and the person who approved it. 4. **4. Controlled rollout** (In a project, weeks 6-8): The automation runs alongside the manual process and results are compared case by case. We switch over when the owner accepts the result, and we measure the exception share on the way. 5. **5. Handover + review cycle** (In a project, weeks 8-9): We hand over the procedure, train the owner and the deputy, and set the date of the first review and who signs it. ### FAQ **Q: What does a documented process mean in practice?** Three documents, each with a named owner: a process description (what happens and in which systems), a procedure (how the automation performs it, and what a person does when it stops) and a change log (what changed, when, on whose approval). This is the same shape a procedure has in an ISO 9001 quality system, so it fits into an existing one without being rewritten. **Q: Why does ISO 9001 matter for an automation?** Robotic automation of business processes is within the scope of our ISO 9001:2015 certificate, which means we build automations inside a quality management system audited by DNV: documented, versioned, reviewed. For you it means an automation that passes your own internal audit and your customer's audit, because it has an owner, a version history and a record of approvals. **Q: Which tools do you use?** The ones your team can operate afterwards. UiPath and Power Automate where they are already licensed, n8n or plain scripts where they are not. Where a step has to read a document, an email or a transcript, we add a model-based step with a confidence threshold and a route to a person below it. We do not build or sell an orchestration platform of our own; the automation runs in your environment, on tools you own. **Q: Can you take over an automation someone else built?** Yes. We start by writing down what it does today, which is often the first time anyone has, then decide per step whether to keep, rebuild or retire it. What you get at the end is the same set of documents as for a new automation. **Q: Who maintains it after handover?** Your owner, following the procedure. We train the owner and a deputy and set a review cycle with a date and a signature. If you would rather we ran the reviews, that is available under AI Application Maintenance; the documentation stays yours either way. **Q: How do you decide what to automate and what to leave manual?** Steps that are stable and rule-based are automated first. Steps that need judgement stay with a person and get a better interface to the automation, such as a queue or a checklist. We write down which is which and why, so the next reviewer can revisit the decision instead of guessing. ### Related - https://23minds.com/services/operate-measure-maintain/app-maintenance - https://23minds.com/services/operate-measure-maintain/cost-model-optimization --- ## Legacy Modernization - Build & Modernize **URL:** https://23minds.com/services/build-automate-modernize/legacy-modernization **Service type:** Legacy system modernization **Anchor:** Build, Automate & Modernize (Build & Modernize) > AI-assisted refactoring and re-platforming for legacy systems blocking your roadmap - incremental strangler-fig modernization instead of a rewrite that takes several quarters. ### Summary 23Minds modernizes legacy systems blocking product roadmaps. The engagement assesses the system, identifies strangler-fig boundaries, and replaces components incrementally using AI-assisted refactoring at a fraction of full-rewrite cost. Typical engagements: PHP/Perl/older .NET monoliths, legacy Java EE, jQuery-era frontends, untyped JavaScript / legacy Python codebases. Output is a modernized system that runs alongside the legacy until the legacy can be retired safely. ### Who it's for - CTOs whose roadmap is blocked by a system the team is afraid to touch - Engineering leaders facing a 'rewrite vs live with it' decision - Mid-stage companies whose first-product codebase no longer matches the team that maintains it - Acquirers integrating a target whose tech stack is materially older than theirs ### Problems we solve - The legacy system has no tests; every change risks production - Documentation is missing or outdated; institutional knowledge sits with one or two engineers - A full rewrite is too expensive to fund; living with the legacy costs more each quarter - Hiring is hard because new engineers do not want to maintain the old stack ### What you get - Legacy system assessment (architecture, dependencies, risk hotspots, modernization options) - Strangler-fig modernization roadmap with sequenced phases and budget per phase - Modernized components running in production alongside the legacy - Test coverage and documentation for both modernized and legacy boundaries - Knowledge transfer to your team - pair sessions, written architecture docs ### How we work 1. **1. Assessment** (Week 1-3): Read the codebase under NDA. Interview engineers who maintain it. Run static analysis. Map dependencies. 2. **2. Roadmap design** (Week 3-4): Identify strangler-fig boundaries. Sequence phases by risk and roadmap unlock. Budget per phase. 3. **3. Modernization sprints** (Week 4-N): Replace components phase-by-phase. Each phase ships behind a routing layer running both old and new in parallel. 4. **4. Legacy retirement** (After each phase): Once a component is fully replaced and stable, retire the legacy path. Repeat until the legacy is gone. ### FAQ **Q: Can you really modernize incrementally, not as a big-bang rewrite?** Yes - strangler-fig is the standard pattern. We build the routing layer that runs old and new in parallel, replace one component at a time, and retire the old code only after the new path is stable in production. Big-bang rewrites are reserved for cases where strangler-fig is genuinely impossible. **Q: What does AI-assisted refactoring actually do?** AI tools accelerate the tedious parts: reading unfamiliar code, generating tests for code that has none, translating between idioms (e.g. callback-style to async/await), proposing refactors that humans review. The engineering judgment stays with our team; the volume work gets faster. **Q: What legacy stacks have you modernized?** PHP (Symfony 1.x, custom legacy), older .NET (Framework 4.x ASP.NET WebForms / MVC), Java EE / Spring Boot pre-2.x, jQuery + server-rendered frontends, untyped Node.js codebases, legacy Python 2 / early 3. **Q: What if our codebase has no tests at all?** Common starting state. Phase 1 of modernization typically includes building a test scaffold around the components we will replace - generated with AI assistance, reviewed by our engineers. Tests come before refactor, always. **Q: Can we keep the legacy system running while you modernize?** Yes - that is the point of strangler-fig. The legacy keeps serving production traffic while new components come online behind a routing layer. Cutover per component is a configuration change, not a release. ### Related - https://23minds.com/services/build-automate-modernize/ai-powered-custom-development - https://23minds.com/services/evaluate-audit-secure/test-coverage - https://23minds.com/services/operate-measure-maintain/app-maintenance --- # Operate, Measure & Maintain (anchor 04) **URL:** https://23minds.com/services/operate-measure-maintain **Highlight:** Telemetry & LLM observability > Observability, telemetry, cost optimization and ongoing maintenance for AI systems already in production - so they keep working as your data and usage change. ### Summary 23Minds operates AI in production for teams that need their systems to keep working as data, usage and providers shift. The work covers LLM observability (tracing, eval pipelines, drift detection); telemetry and analytics for AI products (what to measure, what to alert on); LLM cost and model optimization audits that compare model prices with actual usage and the answer quality you need; and ongoing application maintenance for AI-touched systems. The cost work starts from provider price lists, checked on 25 September 2026. At Anthropic a prompt cache read costs 0.1x the base input token price and a five-minute cache write 1.25x. OpenAI bills cached input on GPT-5.6 and newer models at 0.1x as well, and Google's Gemini API lists cached tokens at 10% of the input price for current models. Model retirements set the maintenance calendar: Anthropic gives at least 60 days' notice for publicly released models, OpenAI at least six months for generally available ones. ### Who it's for - Engineering teams running LLM features in production with growing cost surprises - Product leaders who cannot tell whether their AI feature is actually working for users - CFOs and finance partners asking why the LLM bill keeps growing - DevOps and SRE teams adding LLM-backed services to their on-call rotation ### Problems we solve - LLM spend is growing faster than traffic and no one can tell why - There is no signal whether prompt changes made the product better or worse - An LLM provider deprecated a model and the team has no migration plan - Customer complaints about AI quality cannot be tied back to specific behavior in production ### Practices under this anchor - LLM Observability - https://23minds.com/services/operate-measure-maintain/llm-observability - Product Analytics for AI Features - https://23minds.com/services/operate-measure-maintain/telemetry-analytics - LLM Cost Optimization - https://23minds.com/services/operate-measure-maintain/cost-model-optimization - AI Application Maintenance - https://23minds.com/services/operate-measure-maintain/app-maintenance ### FAQ **Q: What savings can an LLM cost audit find?** Whatever the measurement on your system shows; we do not promise a percentage up front. The savings come from four mechanisms: a higher prompt cache hit rate, routing tasks to smaller models where tests confirm the required quality, prompt compression and removing redundant retries. The audit package ends with a written report on the measured effect of the three changes it implements. At Anthropic and on OpenAI's newest models a cache read costs a tenth of the input price. **Q: What observability stack do you use?** OpenTelemetry-based where possible. We integrate with Datadog, Honeycomb, Grafana, Posthog and dedicated LLM observability tools (Langfuse, Arize, Helicone) depending on what is already in place. The OpenTelemetry semantic conventions for generative AI moved to their own repository in semconv 1.42.0 (12 June 2026) and still have Development status, so attribute names can change between releases. **Q: How do you measure whether prompt changes improved the product?** Eval pipelines: golden test sets, side-by-side comparisons against a baseline, regression alerts on metrics that matter. We design the eval rubric for your product specifically. Answer quality can change even when you do not change the application: Chen, Zaharia and Zou measured GPT-4's accuracy at identifying prime numbers falling from 84% in March 2023 to 51% in June 2023. **Q: Do you handle model migrations when a provider deprecates a model?** Yes. Provider migrations (e.g., Claude 4.6 to 4.7, GPT-4 to GPT-4o) are a standard maintenance engagement: we re-baseline evals, run regression tests and migrate prompts with measured before-after on quality and latency. Provider rules: Anthropic announces the retirement of a publicly released model at least 60 days ahead, OpenAI gives at least six months for generally available models and at least three for specialised variants, and Google lists shutdown dates as the earliest possible. In practice, Anthropic retired nine model versions on six dates between October 2025 and August 2026, with 60 to 189 days' notice. **Q: Is maintenance a retainer or a fixed engagement?** Both work. Retainer fits teams with continuous AI features in production. Fixed engagements (provider migration, cost audit, eval setup) fit teams with a specific need. --- ## LLM Observability - Operate & Measure **URL:** https://23minds.com/services/operate-measure-maintain/llm-observability **Service type:** LLM observability and evaluation engineering **Anchor:** Operate, Measure & Maintain (Operate & Measure) > Tracing, eval pipelines and drift detection for LLM and agentic systems in production - sessions, turns, steps, tool calls and subagents, with cost and quality attached to each. ### Summary 23Minds implements LLM observability for production systems. The service installs tracing over the entities an agentic system actually has - sessions, turns, steps, tool calls and subagents rather than isolated model calls - builds eval pipelines that score new prompt and model versions against your test sets, sets up drift detection, and integrates the signals with your existing observability stack. The test set built during an evaluation stays with you as a CI gate and a production monitor, and the team maintains and extends it after every model or prompt change. OpenTelemetry-based where possible; the service works with Datadog, Honeycomb, Grafana, Langfuse, Arize, Helicone, Braintrust, LangSmith, W&B Weave, Confident AI and Galileo, helps you pick, and at high volume shows where self-hosting beats SaaS. ### Who it's for - Engineering teams whose LLM features ship blind - no visibility into what's happening - Teams running multi-step agents where a failure is three tool calls deep and nobody can find it - Product leaders unable to tell whether prompt iterations improved or regressed the product - SRE teams adding LLM services to their on-call rotation - ML/AI engineering leads needing eval-driven prompt development ### Problems we solve - An agent run fails and nobody can reproduce which step, tool call or subagent broke it - Prompt and model changes ship without measurement; quality regressions are invisible - An audit produced a good test set once and it went stale the week the model changed - Latency P99 doubles overnight and nobody can pinpoint the cause - Provider returns a wrong answer; there is no log of the request to debug from ### What you get - Tracing across agentic entities - sessions, turns, steps, tool calls, subagents - with prompt, response, latency, cost and version on each - Eval pipeline with your test sets and CI-integrated regression alerts - Your audit test set handed over as a CI merge gate and a production monitor on the same thresholds, with a routine for extending it per model or prompt change - Drift detection on outputs (semantic drift, latency drift, cost drift) - Dashboards: per-feature quality, per-feature cost, per-user behavior - Runbooks for the on-call team: how to debug an LLM incident in 15 minutes ### How we work 1. **1. Stack discovery** (Week 1): Map current LLM and agent calls across your codebase. Inventory features, prompts, providers, existing test sets and observability tooling. 2. **2. Instrumentation** (Week 2-3): Wrap sessions, turns, steps, tool calls and subagents with tracing. Forward to the chosen backend and validate every run surfaces end to end. 3. **3. Eval pipelines + CI gate** (Week 3-4): Build test sets per feature from real traffic and from prior evaluation findings. Wire eval runs into CI as a merge gate and mirror the same thresholds as a production monitor. 4. **4. On-call training + handover** (Week 4): Walk the on-call team through dashboards, runbooks and incident scenarios. Hand over the test set as your asset, in your repository. 5. **5. Maintenance retainer (optional)** (Ongoing): We extend the test set and rerun the regression after every model or prompt change, and report what moved and why. ### FAQ **Q: Which observability or eval backend do you recommend?** Depends on what you already have. If you run Datadog or Honeycomb, we extend those. If LLM-specific is preferred: Langfuse, Arize, Helicone, Braintrust, LangSmith, W&B Weave, Confident AI, Galileo. We are tool-agnostic, help you pick against your volume and data boundaries, and above a certain request volume model where self-hosting (Langfuse, Phoenix) comes out cheaper than SaaS. **Q: What if the eval vendor we pick is acquired, sunset or repositioned?** It happens on this market, and it is why we do not build your practice on one vendor. Test sets, scoring definitions and traces stay in portable form in your repository, and we instrument through OpenTelemetry where the backend allows it. Platforms consolidate; the competence and your own test sets stay yours, so a migration is a week of work rather than a rebuild. **Q: Can you observe LLM calls without changing application code?** Partially - providers like OpenAI and Anthropic offer per-request logs through their consoles. For production-grade observability (trace context, user attribution, cost attribution, agent step structure) we usually wrap calls in a thin SDK layer. **Q: What is an eval pipeline?** A test suite for LLM and agent outputs. The test set defines what a right answer looks like; eval runs score new prompt and model versions against it; CI gates merges if quality regresses, and the same thresholds run as a production monitor. Standard practice for any team treating prompts as production code. **Q: Do you handle data privacy in traces?** Yes. Tracing can be configured to redact PII before logs leave your infrastructure, mask prompt sections, or store full prompts only on isolated infrastructure. We design the redaction policy with your security team. **Q: What does this cost to run monthly?** Three separate items. The tracing backend costs what your request volume and chosen tool cost; self-hosted Langfuse has no licence cost but has to be maintained. The retainer is in the price list on this page, by level. On-call and incident handling on our side is agreed separately. We cost both backend options against your own volume in the stack discovery phase, before you choose anything. ### Related - https://23minds.com/services/operate-measure-maintain/telemetry-analytics - https://23minds.com/services/operate-measure-maintain/cost-model-optimization - https://23minds.com/services/evaluate-audit-secure/production-readiness --- ## Product Analytics for AI Features - Operate & Measure **URL:** https://23minds.com/services/operate-measure-maintain/telemetry-analytics **Service type:** Product analytics and telemetry engineering **Anchor:** Operate, Measure & Maintain (Operate & Measure) > Product telemetry and analytics for AI-touched products - what to measure, what to alert on, what to put on the dashboard so product, engineering and leadership are looking at the same picture. ### Summary 23Minds designs and implements product telemetry for AI-touched products. The service translates product questions ('is the AI feature actually used?', 'are users abandoning at the AI step?', 'which prompt version drives revenue?') into events, dashboards and alerts. Output: an event taxonomy, instrumentation across web/mobile/backend, dashboards for product/engineering/leadership and a roadmap for what to measure next. ### Who it's for - Heads of product who cannot tell whether their AI feature is helping users - Growth teams running A/B tests on prompt versions or AI feature rollouts - Engineering managers building data signals into product decisions - Founders launching AI-first products without an in-house analytics team ### Problems we solve - Product is shipping AI features blind - no idea what users actually do with them - Existing analytics tracks page views but misses AI-specific user moments (prompt edits, accept/reject, regenerate) - Each team has its own dashboard with different numbers; leadership cannot trust any of them - Alerts fire for things nobody cares about; real problems pass unnoticed ### What you get - Event taxonomy (AI-specific moments: prompt sent, output rendered, accepted, rejected, regenerated, etc.) - Instrumentation across web, mobile and backend with version tracking - Three dashboards: product (feature health), engineering (system health), leadership (business KPIs) - Alert policy: what fires, who gets paged, what the runbook says - Quarterly review cadence to evolve what is measured as the product evolves ### How we work 1. **1. Question discovery** (Week 1): Interview product, engineering and leadership. Write down the questions each role needs answered. Prioritize. 2. **2. Event taxonomy** (Week 2): Translate questions into events. Define AI-specific moments. Document properties and versioning policy. 3. **3. Instrumentation + dashboards** (Week 2-3): Instrument across the stack. Build the three dashboards. Set the alert policy. 4. **4. Handover + review cadence** (Week 3, then quarterly): Walk each audience through their dashboard. Set quarterly review. Iterate the event list at +3 months. ### FAQ **Q: What analytics platforms do you work with?** Posthog, Mixpanel, Amplitude, Segment as a router, Snowplow for self-hosted. For LLM-specific signals we often pair with Langfuse or Helicone. We pick based on your stack, not vendor preference. **Q: Do you do data warehousing?** Light-touch. We send analytics events to your warehouse (Snowflake, BigQuery, Redshift, ClickHouse) but do not build full data warehouse models - that is a separate engagement. **Q: How is this different from LLM Observability?** LLM Observability is about the LLM call itself (latency, cost, output drift). Product Analytics for AI Features is about the user and the product (does the feature work, do users come back, does it drive revenue). Most clients buy both. **Q: Can you instrument mobile too?** Yes. iOS (Swift) and Android (Kotlin), plus React Native and Flutter. We respect platform-specific privacy requirements (ATT on iOS, scoped storage on Android). **Q: How do you handle privacy and consent?** Consent gating is wired into instrumentation. Events that touch PII are tagged for consent-respecting routing. Privacy review is part of the instrumentation phase, not an afterthought. ### Related - https://23minds.com/services/operate-measure-maintain/llm-observability - https://23minds.com/services/operate-measure-maintain/cost-model-optimization - https://23minds.com/services/evaluate-audit-secure/production-readiness --- ## LLM Cost Optimization - Operate & Measure **URL:** https://23minds.com/services/operate-measure-maintain/cost-model-optimization **Service type:** LLM cost optimization audit **Anchor:** Operate, Measure & Maintain (Operate & Measure) > An LLM cost and model optimization audit shows where the spend in a production system comes from. It then implements the changes that can lower it: prompt caching, model routing, prompt compression and retry rules. The report compares cost and quality test results before and after. ### Summary 23Minds runs LLM cost and model optimization audits for engineering teams whose LLM bill grows faster than traffic. The engagement instruments the system for per-call cost attribution, audits current usage, recommends and implements provider-side savings (prompt caching, smaller-model routing, prompt compression, retry tuning) and delivers a measured before/after with eval-protected quality. The size of the saving depends on the starting point; it is measured on your system, not promised up front. ISO 9001:2015 quality assurance backing. ### Who it's for - Engineering teams whose monthly LLM bill grew past EUR 10k and keeps climbing - CFOs and finance partners asking why LLM spend exceeds plan - Product engineering leaders shipping AI features whose unit economics are upside-down - Mid-stage companies preparing for a funding round needing defensible AI cost numbers ### Problems we solve - LLM spend grows faster than user traffic and nobody knows why - Prompt cache hit rate is low or not measured; every call pays full price - All features route to the most expensive model regardless of stakes - Retries on transient errors silently multiply the bill ### What you get - Cost attribution dashboard - per feature, per user segment, per model - Optimization recommendations ranked by saving × effort - Implementation of the top wins (caching, routing, prompt rework, retry policy) - Eval-protected quality measurement: same or better quality after optimization - Written audit report with measured before/after savings ### How we work 1. **1. Cost instrumentation** (Week 1-2): Instrument per-call cost attribution. Run for 1-2 weeks to capture a representative cost picture. 2. **2. Audit + recommendations** (Week 2): Analyze cost data. Identify top savings opportunities. Write recommendations with effort estimates. 3. **3. Implementation** (Week 2-3): Implement top wins. Set up eval-protected rollout: quality must hold before cost drop counts. 4. **4. Measurement + report** (Week 3, up to 4 weeks after rollout in a project): Measure before/after over 2-4 weeks. Deliver audit report with documented savings. ### FAQ **Q: How do you measure the savings?** We compare model API spend for comparable tasks and load: the period after implementation against a baseline period before the audit, of the same length in the package and month on month in ongoing work. Traffic growth is excluded from the comparison, which needs baseline data on calls and costs. The result depends on the starting point: teams already using caching see less, teams that have never optimized see more. We do not promise a percentage up front. **Q: Will optimization degrade quality?** We protect against this with eval pipelines. Every optimization is tested against a golden set; we only ship changes that hold or improve quality. Quality is the constraint, cost is the optimization target. **Q: What provider features matter most?** The audit shows which changes have the most potential in your application. The usual candidates are prompt caching, routing tasks to smaller models where tests confirm the quality, prompt compression (removing redundant context) and retry tuning (no silent retries where the error will repeat). The price lists separate the cost of reading from the cache and of writing to it: at Anthropic a cache read costs 0.1x the base input price, a five-minute cache write 1.25x and a one-hour write 2x the base input token price; OpenAI bills cached input on GPT-5.6 and newer models at 0.1x, with a 30-minute cache lifetime (checked 25 September 2026). **Q: Do you do this for one provider or multiple?** Both. Multi-provider clients often have routing logic that picks the cheapest qualified model per task - we optimize that routing as part of the engagement. Single-provider clients optimize within the provider's pricing surface. **Q: What does the engagement cost?** The entry package for one application has a fixed price, listed on this page. A larger scope is quoted after the intro call, by the size of the workload. The payback is calculated in the audit report on your own numbers, not promised up front. **Q: How did Uber rein in spending on AI coding tools?** Uber's CTO told The Information in April 2026 that AI coding tools, mainly Claude Code, had used up the company's AI budget for the year within months, and in June 2026 Uber confirmed to Bloomberg that each AI coding tool is capped at USD 1,500 per employee per month. In August 2026 the CTO credited better prompt caching, a change of default model and cost visibility for engineers with bringing the cost per token down (Fortune). The example concerns coding tools. In an application built on a language model, the audit checks which features generate the cost, how the cache is used and whether the model fits the task. ### Related - https://23minds.com/services/operate-measure-maintain/llm-observability - https://23minds.com/services/operate-measure-maintain/app-maintenance - https://23minds.com/services/build-automate-modernize/ai-powered-custom-development --- ## AI Application Maintenance - Operate & Measure **URL:** https://23minds.com/services/operate-measure-maintain/app-maintenance **Service type:** Application maintenance and support **Anchor:** Operate, Measure & Maintain (Operate & Measure) > Ongoing maintenance for AI-touched systems - provider migrations, prompt tuning, dependency upgrades and the quiet engineering work that keeps production systems running as the AI landscape shifts. ### Summary 23Minds provides ongoing maintenance for AI-touched applications. AI systems need maintenance that traditional applications do not: provider migrations when a model is deprecated, prompt tuning as inputs evolve, eval re-baselining, dependency upgrades for the LLM SDK layer, cost monitoring as spend drifts. Retainer model fits teams with continuous AI features; fixed engagements fit specific events like a provider migration. Provider notice before a model retirement differs: at least 60 days at Anthropic for publicly released models, at least six months at OpenAI for generally available ones (checked 25 September 2026). ### Who it's for - Engineering teams with AI features in production who need part-time senior support - CTOs whose team built the AI feature and moved on; nobody owns it now - Product teams whose AI providers deprecate models faster than the team can react - Mid-stage companies extending or maintaining AI features without growing the team ### Problems we solve - Provider deprecates a model; the team has no migration plan and no time to write one - Prompt that worked at launch produces worse outputs six months later - drift - LLM SDK version is stuck at launch-day version; security patches piling up - Cost trends are rising slowly enough that nobody noticed until the quarterly review ### What you get - Monthly maintenance hours covering the issues above (retainer) - Provider migration plans + execution when models deprecate (eval-protected) - Quarterly prompt tune-up: re-eval, regression check, minor tuning - Dependency upgrade cadence: SDKs, observability libraries, eval frameworks - Quarterly written report: what changed, what to expect, what to budget for next quarter ### How we work 1. **1. Handover** (Week 1-2): Read the system. Map dependencies, prompts, eval setup, observability and on-call procedures. Document gaps. 2. **2. Stabilization (if needed)** (Week 2-4 (one-time)): Address critical maintenance debt before steady-state retainer: missing evals, ungoverned prompts, stale SDKs. 3. **3. Steady-state retainer** (Ongoing): Monthly maintenance hours, quarterly check-ins, ad-hoc support for provider events or incidents. 4. **4. Quarterly review** (Quarterly): Written report on what we touched, what is drifting, what to budget next quarter. ### FAQ **Q: Retainer or fixed engagement?** Both work. Retainer (10-40 hours/month) fits teams with continuous AI features in production. Fixed engagements (provider migration, eval re-baselining, prompt re-tune) fit teams with a specific event. **Q: What if there is a production incident?** Retainer clients get ad-hoc incident support - we join the bridge, help debug, write the post-mortem. SLAs are agreed in the retainer contract. **Q: Do you handle full DevOps / SRE?** We handle AI-specific operations (prompt drift, model migrations, eval pipelines, LLM cost monitoring). Generic SRE work (Kubernetes, infrastructure-as-code, traditional alerting) is in scope only when it intersects with the AI features. **Q: How do model migrations work?** Standard maintenance event. We re-baseline eval against the new model, run regression tests, migrate prompts where the new model needs different patterns, measure before/after on quality, latency and cost. Provider rules set the calendar: Anthropic announces the retirement of a publicly released model at least 60 days ahead, OpenAI gives at least six months for generally available models and at least three for specialised variants, and preview models can get much shorter notice. In practice, Anthropic retired nine model versions on six dates between October 2025 and August 2026, with 60 to 189 days' notice. Answer quality can also change without a retirement: GPT-4's accuracy at identifying prime numbers fell from 84% in March 2023 to 51% in June 2023 (Chen, Zaharia and Zou). **Q: Can you maintain code we did not build?** Yes. Handover phase covers reading and documenting the system. We may need to address maintenance debt before steady-state retainer becomes possible. ### Related - https://23minds.com/services/operate-measure-maintain/llm-observability - https://23minds.com/services/operate-measure-maintain/cost-model-optimization - https://23minds.com/services/build-automate-modernize/ai-powered-custom-development --- ================================================================ POLISH CONTENT ================================================================ # Pełna treść serwisu 23Minds - wersja polska _Generowane przy każdym buildzie z tych samych danych, z których powstają strony (anchors.pl.ts, przewodniki, messages/pl.json)._ --- # Strona główna - 23Minds **URL:** https://23minds.com/pl > 23Minds tworzy oprogramowanie z AI i prowadzi niezależną ewaluację kodu pisanego przez AI. Bezpieczeństwo, ewaluacja kodu, szkolenia inżynierskie. ## Tworzenie i inżynieria oprogramowania z AI. Niezależna ewaluacja kodu pisanego przez AI. Napiszcie, co chcecie zbudować, naprawić albo sprawdzić. Inżynier odpowiada w ciągu jednego dnia roboczego. - Certyfikat ISO 9001:2015 (DNV Business Assurance, 10000439701-MSC-RvA-POL) - Siedziba: ul. Wawrzyniaka 6W, 70-392 Szczecin - Miejsca spotkań: Szczecin, Warszawa, Zielona Góra, Kraków - Języki: polski i angielski - Czas odpowiedzi: jeden dzień roboczy ## Tak wygląda ewaluacja kodu, który powstał z AI. Audyt obejmuje próbkę plików albo pull requestów z waszego repozytorium. Każdy element próbki dostaje ocenę w czterech wymiarach: poprawność, bezpieczeństwo, utrzymywalność i jakość testów. Wynik to raport z ustaleniami uszeregowanymi według wagi (taki jak ten obok) i omówienie z zespołem. Audyt działa jednorazowo albo jako stały przegląd, w trakcie prac i po wdrożeniu. Kod czyta i ocenia inżynier, a nie narzędzie, a ustalenia trafiają do waszego systemu zgłoszeń. ## Rytm pracy, który da się zaplanować. - **Tydzień 1 - Zakres na piśmie** Rozmowa wstępna i uzgodniony zakres pierwszego zlecenia: co dostaniecie, w jakiej kolejności i za ile. Bez zobowiązań po waszej stronie. - **Miesiąc 1 - Raport albo działający fragment systemu** Pierwszy raport z audytu albo pierwszy działający fragment systemu na podglądzie. Ustalenia trafiają do waszego systemu zgłoszeń. - **Kwartał 1 - Przeglądy i testy po poprawkach** Stały przegląd, ponowny test po poprawkach, bramki jakości w waszym procesie. Zespół pracuje z AI według ustalonych zasad. - **Rok 1 - Procedury i przeszkolony zespół** Procedury, kryteria oceny i przeszkoleni ludzie są wasi. W stałej współpracy, jeśli jej chcecie, 23Minds zostaje przy trudnych przypadkach i zmianach w narzędziach. Terminy są orientacyjne i zależą od zakresu; konkretne daty wynikają z rozmowy wstępnej. ## Szkolenia z AI dla zarządu, zespołów produktowych i inżynierii. Programy dla zespołów biznesowych, produktowych i inżynierskich: warsztaty rozliczane za dzień albo programy dla stałej grupy na kilka tygodni. Program szkolenia uwzględnia narzędzia i zadania waszego zespołu. Dofinansowanie szkoleń. Wybrane szkolenia z AI są dostępne w Bazie Usług Rozwojowych, a o dofinansowaniu i jego wysokości decyduje operator, zależnie od wielkości firmy i województwa. Kwalifikację sprawdza się przed planowaniem, na rozmowie wstępnej. ### Programy szkoleń - **GOV-101 Zasady korzystania z AI i podstawy AI Act** (Zarząd i zgodność): Klasyfikacja systemów, nadzór człowieka, zasady korzystania z AI. - **BIZ-201 Wybór zastosowań AI i planowanie pilotażu** (Zespoły produktowe): Od pomysłu do pilotażu z datą końca i decyzją. - **SEC-201 Bezpieczne kodowanie z asystentami AI** (Inżynieria): Błędy typowe dla kodu od asystentów, uprawnienia agentów, reguły przeglądu. - **ENG-101 Praca z asystentami kodowania na co dzień** (Inżynieria): Claude Code, Cursor, Copilot na repozytorium zespołu. - **BIZ-101 Podstawy AI dla zespołów biznesowych** (Wszystkie zespoły): Prompty do zadań z pracy, dane, których nie wolno wysłać, sprawdzanie odpowiedzi. - **ENG-201 Przegląd kodu pisanego przez AI** (Inżynieria, QA): Co sprawdzać w rozbudowanej zmianie napisanej przez AI i co blokuje scalenie. ## Pytania przed rozpoczęciem współpracy. **Jak zaczynacie pracę z nowym klientem?** Od rozmowy wstępnej do 60 minut z inżynierem, na której poznajemy waszą sytuację. Potem ustalamy zakres pierwszego zlecenia w stałej cenie: audyt kodu, warsztat, sprint PoC albo pilotaż automatyzacji, z nazwanymi rezultatami i terminem. **Ile kosztuje zlecenie?** Każda praktyka ma pakiet wejściowy z ceną podaną na stronie praktyki: od dnia szkolenia po audyt jednego repozytorium. Tam, gdzie nakład zależy od wielkości i złożoności systemu, cena jest podana jako cena od i staje się stała po ustaleniu zakresu na rozmowie wstępnej, bez ukrytych kosztów. Większe projekty i stałą współpracę wyceniamy po rozmowie, etapami. **Czy szkolenia mogą być dofinansowane?** Wybrane szkolenia z AI są dostępne w Bazie Usług Rozwojowych; o dofinansowaniu i jego wysokości decyduje operator, zależnie od wielkości firmy i województwa. Sprawdzamy to z wami na rozmowie wstępnej. **Kto będzie pracował nad naszym zleceniem?** Inżynierowie, którzy ten kod piszą, audytują i utrzymują; ci sami, z którymi rozmawiacie na rozmowie wstępnej. Kompetencja zostaje u was: procedury, kryteria oceny i przeszkoleni ludzie są wasi. Efekty mierzymy na wskaźnikach uzgodnionych przed startem. **Co obejmuje wasz certyfikat ISO 9001?** Projektowanie i tworzenie aplikacji webowych i mobilnych, e-commerce i strony internetowe, utrzymanie aplikacji, szkolenia IT i doradztwo, marketing internetowy oraz zrobotyzowaną automatyzację procesów biznesowych. Certyfikat wydał DNV Business Assurance. ## Napiszcie, co chcecie zbudować, naprawić albo sprawdzić. Inżynier odpowiada w ciągu jednego dnia roboczego, po polsku albo po angielsku. Bez prezentacji sprzedażowej. Serwis jest zorganizowany wokół obszarów: Szkolenia i wdrożenia, Ocena i bezpieczeństwo, Budowa i modernizacja, Utrzymanie i pomiary. --- # O nas - 23Minds **URL:** https://23minds.com/pl/o-nas > Firma inżynierska: oprogramowanie budowane z AI i niezależna ewaluacja kodu pisanego przez AI. 23Minds buduje oprogramowanie z pomocą AI, audytuje kod pisany przez AI i sprawdza jego bezpieczeństwo, szkoli zespoły i utrzymuje systemy. Ewaluacja jest niezależna, bo dotyczy kodu, którego zespół 23Minds nie pisał: waszego albo waszego dostawcy. Marka należy do DFZOO.COM Sp. z o.o., spółki z certyfikatem ISO 9001:2015; dane rejestrowe są niżej, w sekcji o podmiocie prawnym. ## Tę stronę buduje zespół inżynierski 23Minds razem z Claude'em. Strona 23Minds, którą czytacie (kod, treści, dane strukturalne, routing, wdrożenia), powstaje z pomocą Claude'a, asystenta AI od Anthropic, pod kierunkiem inżynierów 23Minds. To ten sam sposób pracy z AI, którego Instytut AI uczy zespoły klientów. Ta strona jest przykładem konkretnego procesu tworzenia oprogramowania, tego samego, który 23Minds oddaje w praktyce Budowa oprogramowania z AI: automatyczne kontrole sprawdzają każdą zmianę w kodzie, a inżynier zatwierdza publikację. Szczegóły są na stronie tej praktyki. ## Jak pracują inżynierowie 23Minds. - **Prowadzona przez inżynierów** - Konsultanci 23Minds są inżynierami. Trenerzy piszą i wdrażają kod. Audyty przygotowują te same osoby, które budują podobne systemy. Sprzedaż i realizacja to ten sam zespół. - **Certyfikat ISO 9001:2015** - System zarządzania jakością certyfikowany przez DNV Business Assurance (10000439701-MSC-RvA-POL). Dla działu zakupów to sygnał, że sposób prowadzenia projektów jest powtarzalny i audytowalny. - **Efekty mierzone na uzgodnionych wskaźnikach** - Miarą projektu są wskaźniki uzgodnione z klientem przed startem, zależne od celu projektu: na przykład koszt obsługi jednego zapytania, czas odpowiedzi systemu, liczba błędów, częstość wdrożeń. Raporty piszą ci sami inżynierowie, którzy prowadzili projekt. ## DFZOO.COM Sp. z o.o. Marka 23Minds należy do DFZOO.COM Sp. z o.o. Spółka figuruje w KRS od 2019 roku i ma siedzibę w Szczecinie. Jest zarejestrowana jako podatnik VAT UE. Zespół działa na rynku od 2012 roku i pracuje dla klientów w Polsce i za granicą. Spółka ma certyfikat systemu zarządzania jakością ISO 9001:2015 wydany przez DNV Business Assurance (nr 10000439701-MSC-RvA-POL). ## Zakres certyfikatu ISO 9001:2015 System zarządzania jakością certyfikowany przez DNV Business Assurance, numer certyfikatu 10000439701-MSC-RvA-POL. Zakres obejmuje: - Projektowanie i tworzenie aplikacji webowych i mobilnych - E-commerce i strony internetowe - Utrzymanie aplikacji - Szkolenia IT i doradztwo - Marketing internetowy - Zrobotyzowaną automatyzację procesów biznesowych w systemach informatycznych ## Siedziba i miejsca spotkań - **Szczecin** (siedziba): ul. Wawrzyniaka 6W, 70-392 Szczecin, Polska. Godziny biura: poniedziałek-piątek, 09:00-17:00 CET. - **Warszawa**: spotkania po umówieniu. - **Zielona Góra**: spotkania po umówieniu. - **Kraków**: spotkania po umówieniu. --- # Kontakt - 23Minds **URL:** https://23minds.com/pl/kontakt > Napiszcie, co chcecie zbudować, naprawić albo sprawdzić. Nieważne, czy macie już u siebie AI, czy dopiero zaczynacie. Odpowiedź w ciągu jednego dnia roboczego, po polsku albo po angielsku. - Odpowiedź w ciągu jednego dnia roboczego - NDA przed rozmową, jeśli tego potrzebujecie - Rozmowę prowadzi inżynier, nie handlowiec ## Siedziba i miejsca spotkań - **Szczecin** (siedziba): ul. Wawrzyniaka 6W, 70-392 Szczecin, Polska. Godziny biura: poniedziałek-piątek, 09:00-17:00 CET. - **Warszawa**: spotkania po umówieniu. - **Zielona Góra**: spotkania po umówieniu. - **Kraków**: spotkania po umówieniu. ## Kontakt - **Nowe projekty i zapytania**: start@23minds.com - Rozmowy wstępne, ustalanie zakresu, odpowiedzi na zapytania ofertowe, pytania działów zakupów. - **Media i partnerstwa**: start@23minds.com - Zapytania od mediów, propozycje wystąpień, partnerstwa i wspólne działania marketingowe. ## Dane rejestrowe - Nazwa prawna: DFZOO.COM Sp. z o.o. (23Minds to marka DFZOO.COM Sp. z o.o.) - NIP / VAT UE: PL8522656040 - KRS: 0000783223 - Adres siedziby: ul. Wawrzyniaka 6W, 70-392 Szczecin --- # Usługi - 23Minds **URL:** https://23minds.com/pl/uslugi > Obszary usług 23Minds: budowa oprogramowania z AI, audyt kodu pisanego przez AI i bezpieczeństwo, utrzymanie i pomiary, szkolenia z dofinansowaniem BUR. Każdy obszar zbiera praktyki z pakietem wejściowym i ceną podaną na stronie. ## Usługi AI dla firm: budowa, audyt, utrzymanie i szkolenia. Wybierzcie zakres: budowa oprogramowania z AI, audyt kodu pisanego przez AI i bezpieczeństwo, utrzymanie i pomiary albo szkolenia. W każdym obszarze znajdziecie praktyki, pakiety wejściowe z ceną i warunki współpracy. Serwis jest zorganizowany wokół obszarów: Szkolenia i wdrożenia, Ocena i bezpieczeństwo, Budowa i modernizacja, Utrzymanie i pomiary. --- ## Obowiązek szkolenia z AI z art. 4 AI Act: program dla każdej roli i dokumenty, które zostają **URL:** https://23minds.com/pl/przewodniki/obowiazek-szkolen-ai-act-artykul-4 **Adres kanoniczny (dla tej strony kanoniczny jest polski):** https://23minds.com/pl/przewodniki/obowiazek-szkolen-ai-act-artykul-4 > Art. 4 AI Act zobowiązuje firmy dostarczające lub stosujące systemy AI do wspierania rozwoju kompetencji w zakresie AI u osób, które obsługują te systemy w ich imieniu. To obowiązek ciągły, a nie jednorazowy webinar. Rozlicza się go dokumentami, które pokazują, co zrobiliście. ### Podsumowanie 23Minds prowadzi szkolenia z kompetencji w zakresie AI, które pomagają firmom i instytucjom działającym w Polsce i w Unii Europejskiej realizować obowiązek z art. 4 rozporządzenia (UE) 2024/1689. Obowiązek stosuje się od 2 lutego 2025 i nie został objęty przesunięciem terminów, które pakiet omnibusowy wprowadził dla systemów wysokiego ryzyka. Program powstaje dla każdej roli: inaczej dla zarządu i zakupów, inaczej dla osób obsługujących system i sprawujących nadzór, inaczej dla zespołu inżynierskiego. Po szkoleniu u klienta zostają artefakty rozliczeniowe: rejestr przeszkolonych, program dla każdej roli z datą, protokół walidacji efektów uczenia się i imienne certyfikaty. DFZOO.COM Sp. z o.o. ma ISO 9001:2015 wydany przez DNV Business Assurance, certyfikat nr 10000439701-MSC-RvA-POL. ### Dla kogo to jest - Zarządy i osoby decydujące o zakupie narzędzi AI, które podpisują oświadczenia w ankietach klienckich i w przetargach - Właściciele procesów, w których działa kupiony system AI, czyli podmioty stosujące w rozumieniu rozporządzenia - Osoby obsługujące systemy AI na co dzień i sprawujące nadzór ze strony człowieka - Zespoły inżynierskie budujące funkcje AI albo integrujące modele dostawców - HR, compliance i działy zakupów, które muszą wykazać, kto i z jakiego programu był szkolony - Instytucje publiczne i samorządy, w których urzędnicy już korzystają z generatywnej AI ### Czego dokładnie wymaga art. 4 Art. 4 rozporządzenia (UE) 2024/1689 ma od 27 lipca 2026 brzmienie nadane rozporządzeniem (UE) 2026/1744. Zobowiązuje dostawców i podmioty stosujące systemy AI do podejmowania środków, które wspierają rozwój kompetencji w zakresie AI wśród ich personelu i innych osób zajmujących się w ich imieniu działaniem i wykorzystaniem tych systemów. Przepis wskazuje też, co należy przy tym uwzględnić: wiedzę techniczną, doświadczenie, wykształcenie i wyszkolenie tych osób, kontekst, w którym systemy mają być wykorzystywane, oraz osoby lub grupy osób, wobec których będą stosowane. Zastrzega też, że obowiązek nie oznacza zapewnienia określonego poziomu kompetencji u poszczególnych osób. W przepisie nie ma liczby godzin, nazwy kursu ani wymogu certyfikatu zewnętrznego. Kryterium jest adekwatność do roli, więc kontrola i klient patrzą na dwie rzeczy: czy program odpowiadał temu, co dana osoba realnie robi z systemem AI, oraz czy da się to wykazać. Zakres podmiotowy jest tu najszerszy w całym rozporządzeniu. Obejmuje również osoby, które nie są waszymi pracownikami, a działają w waszym imieniu: kontraktorów, agencje i podwykonawców obsługujących wasze systemy. Obowiązek stosuje się od 2 lutego 2025 i tej daty nie przesunięto. Rozporządzenie (UE) 2026/1744, czyli pakiet omnibusowy, zmieniło natomiast od 27 lipca 2026 samo brzmienie art. 4. Pierwotny tekst mówił o środkach w celu zapewnienia, w możliwie największym stopniu, odpowiedniego poziomu kompetencji. Nowy wymaga środków, które wspierają rozwój kompetencji. Zastrzega też, że nie chodzi o zapewnienie określonego poziomu u poszczególnych osób. Nowe ustępy zobowiązują Komisję i państwa członkowskie do wspierania tych działań, zwłaszcza w MŚP, a Radę ds. AI do przyjmowania zaleceń. Komisja publikuje przy tym praktyczne przykłady. Obowiązek nadal stosuje się od 2 lutego 2025, a dokumenty mają pokazywać podjęte środki. ### Mapowanie ról na wymagany poziom rozumienia AI To jest punkt, w którym najczęściej powstaje pozorna zgodność: jeden kurs dla wszystkich formalnie odhacza obowiązek, a nie zmienia sposobu, w jaki ludzie pracują z systemem. Poniżej układ, od którego zaczynamy i który potem dopasowujemy do waszych systemów i ról. Kolumna z dowodem jest tu najważniejsza. To ona odpowiada na pytanie, które przychodzi później: czym wykażecie, że osoba na danym stanowisku dostała program odpowiadający jej roli. | Rola | Co ta osoba musi rozumieć | Zakres szkolenia | Dowód, który zostaje | | --- | --- | --- | --- | | Zarząd i osoby decydujące o zakupie | Co firma bierze na siebie przy zakupie systemu AI oraz jakie obowiązki idą za rolą dostawcy, a jakie za rolą podmiotu stosującego | Orientacja w rozporządzeniu, role, klasy ryzyka, konsekwencje umowne i zakupowe | Program z datą i imienny certyfikat | | Właściciel procesu, czyli podmiot stosujący | Do czego system służy, gdzie kończy się jego wiarygodność i kiedy trzeba przerwać albo eskalować | Granice zastosowania, dane wejściowe, monitorowanie, obowiązki podmiotu stosującego | Program dla każdej roli i protokół walidacji efektów uczenia się | | Osoba obsługująca system i sprawująca nadzór | Jak rozpoznać wynik, którego nie wolno przyjąć bez sprawdzenia, oraz co zrobić dalej | Praca na waszym systemie, przypadki graniczne, ścieżka eskalacji, rejestrowanie decyzji | Zadanie praktyczne wykonane na waszym środowisku | | Zespół inżynierski | Skąd biorą się błędy modelu, jak je mierzyć i co zapisać, żeby dało się je odtworzyć | Ewaluacja, testy, rejestrowanie zdarzeń, identyfikowalność, bezpieczeństwo warstwy aplikacyjnej | Wynik testu wiedzy i artefakty z warsztatu | | Marketing, obsługa klienta i osoby publikujące treści | Co wolno opublikować, co wymaga oznaczenia i gdzie kończy się odpowiedzialność narzędzia | Obowiązki przejrzystości, oznaczanie treści, weryfikacja przed publikacją | Lista kontrolna publikacji i imienny certyfikat | | Zakupy, dział prawny i compliance | Czego wymagać od dostawcy i co musi znaleźć się w umowie oraz w rejestrze systemów | Rola dostawcy a rola podmiotu stosującego, dokumentacja, pytania do dostawcy | Wzór pytań do dostawcy i wpis w rejestrze | ### Czego szkolenie nie załatwia Art. 4 to jeden obowiązek z wielu i sam w sobie nie czyni żadnego systemu zgodnym z rozporządzeniem. Piszemy to wprost, bo najczęstszy problem po szkoleniu to nie brak wiedzy, tylko przecenienie tego, co szkolenie pokrywa. - Szkolenie nie zastępuje inwentaryzacji ani klasyfikacji systemów AI: to osobna praca i osobny artefakt - Szkolenie nie tworzy dokumentacji technicznej wymaganej dla systemów wysokiego ryzyka - Certyfikat ze szkolenia nie jest deklaracją zgodności i nie należy go tak przedstawiać w ankietach klienckich ani w przetargach - Szkolenie nie zwalnia z nadzoru ze strony człowieka: nadzór jest wymaganiem architektonicznym z przypisanym właścicielem, a nie stanem świadomości zespołu - Wykładnię przepisu i jej skutki dla waszej sytuacji podpisuje radca prawny, nie my ### Dofinansowanie: BUR, KFS i środki z PARP W Polsce rozmowa o szkoleniu z AI zaczyna się zwykle od pytania o dofinansowanie, więc opisujemy stan wprost, z rozróżnieniem na to, co potwierdziliśmy u źródła, oraz to, co trzeba sprawdzić u operatora. Od 1 stycznia 2026 rolę Rejestru Instytucji Szkoleniowych przejęła Baza Usług Rozwojowych, a dane z RIS nie przeszły automatycznie: każda instytucja rejestruje się sama. Szkolenia finansowane przez urzędy pracy i z Krajowego Funduszu Szkoleniowego realizują podmioty wpisane do BUR. Wpis z możliwością świadczenia usług dofinansowanych wymaga certyfikatu albo akredytacji z listy prowadzonej przez PARP. Lista PARP według stanu na 21 stycznia 2026 wymienia w pozycji 8 certyfikat ISO 9001:2015 w zakresie powiązanym ze świadczeniem usług rozwojowych, wydany przez jednostkę akredytowaną. DFZOO.COM Sp. z o.o. ma certyfikat ISO 9001:2015 wydany przez DNV Business Assurance, nr 10000439701-MSC-RvA-POL. Jego zakres obejmuje między innymi szkolenia i doradztwo informatyczne. Krajowy Fundusz Szkoleniowy na 2026 rok wymienia sztuczną inteligencję wprost. Priorytet nr 3 Ministra do spraw pracy to wsparcie kształcenia ustawicznego w związku z zastosowaniem w firmach nowych procesów, technologii i narzędzi pracy, ze szczególnym uwzględnieniem umiejętności cyfrowych, AI oraz tak zwanych umiejętności zielonych, zwłaszcza gdy powyższe czynniki stanowią zagrożenie utratą pracy. Ostatnia część tego zdania bywa pomijana w materiałach handlowych, a to ona decyduje, czy wniosek trafia w priorytet. Nabór FERS 1.3 pod nazwą Kompetencje z automatyzacji dla transformacji cyfrowej ma alokację 78 000 000 zł, w tym 66 729 000 zł na dofinansowanie, przy poziomie do 85,55% wydatków kwalifikowalnych. Nabór na operatorów zamknięto 18 grudnia 2025. Wybrano po jednym projekcie na makroregion, czyli sześciu operatorów. Wsparcie dla firm rusza od trzeciego kwartału 2026 u operatora właściwego dla waszego makroregionu. Limitów na uczestnika i na przedsiębiorstwo tu nie podajemy, bo kwoty krążące w sieci pochodzą ze źródeł wtórnych. Sprawdzamy je razem z wami u operatora właściwego dla waszego województwa, zanim ustalimy zakres i termin. To samo dotyczy statusu wpisu do BUR w dniu, w którym podpisujecie umowę. ### Gdzie to się psuje i co z tym robimy **Szkolenie się odbyło, dowodu nie ma** Firma robi jeden webinar dla wszystkich, lista uczestników zostaje w kalendarzu albo w logu narzędzia do wideokonferencji, nagranie ląduje na dysku. Pół roku później przychodzi ankieta bezpieczeństwa od klienta z pytaniem, kto był szkolony, z jakiego programu i kiedy. Nikt nie potrafi odtworzyć imiennej listy ani wykazać, że zakres odpowiadał roli, więc odpowiedź brzmi "prowadzimy szkolenia", co w ankiecie znaczy tyle co nic. Co z tym robimy: Zaczynamy od listy osób mających kontakt z systemami AI i porównujemy ją z listą przeszkolonych, więc braki widzicie jako listę imienną jeszcze przed szkoleniem. Po każdej grupie wydajemy rejestr przeszkolonych z datami, program dla każdej roli i imienne certyfikaty, a efekty potwierdzamy testem i zadaniem praktycznym, nie obecnością na spotkaniu. Kompletność rejestru sprawdzamy ponownie na zamknięcie projektu. Co zostaje u was: rejestr przeszkolonych z datami, program dla każdej roli i protokół walidacji efektów uczenia się **Jeden program dla wszystkich** Kurs pod tytułem "AI dla firm" kupuje się raz i puszcza przez całą organizację, bo tak jest taniej i prościej w rozliczeniu. Inżynierowie dostają godzinę o tym, czym jest model językowy, a osoba, która na tym systemie akceptuje albo odrzuca wnioski, nie widzi ani jednego przykładu z własnego ekranu. Obowiązek jest odhaczony, praktyka pracy nie zmienia się o nic, a przy pierwszym wątpliwym wyniku okazuje się, że nikt nie wiedział, co z nim zrobić. Co z tym robimy: Mapujemy role na wymagany poziom rozumienia i budujemy osobny program dla każdej grupy, na materiale z waszych systemów, nie z prezentacji. Poziom wyjściowy sprawdzamy krótkim testem przed szkoleniem, a efekt zadaniem praktycznym wykonanym na waszym środowisku. Grupa, która wypadnie poniżej progu, powtarza moduł, a nie cały kurs. Co zostaje u was: mapa ról z przypisanym poziomem i program dla każdej roli z datą **Szkolenie omija AI, o której nikt nie wie** Zakres ustala się wokół narzędzia, które firma wdrożyła świadomie, na przykład asystenta do kodu albo firmowego czatu. Poza zakresem zostają funkcje AI wbudowane w oprogramowanie kupione wcześniej: podsumowania w systemie zgłoszeń, ranking kandydatów w systemie rekrutacyjnym, generator odpowiedzi w obsłudze klienta. To właśnie przy nich najczęściej stoją obowiązki podmiotu stosującego, a ludzie używają ich codziennie, nie nazywając tego AI. Co z tym robimy: Przed ustaleniem programu robimy krótką inwentaryzację rzeczywistego użycia: lista aplikacji z logowania SSO, pytanie do dostawców o funkcje dołożone w aktualizacjach i ankieta w zespołach. To, co znajdziemy, wchodzi do zakresu szkolenia, a to, co wykracza poza szkolenie, zapisujemy jako listę systemów do klasyfikacji i przekazujemy jako osobny wynik. Co zostaje u was: lista narzędzi z funkcjami AI w rzeczywistym użyciu, z zaznaczeniem, które wchodzą do programu **Program układany pod termin naboru, nie pod role** Harmonogram operatora dofinansowania wyznacza datę, więc zakres dopasowuje się do tego, co da się rozliczyć w tym oknie, a nie do tego, kto czego potrzebuje. Dokumenty rozliczeniowe kompletuje się po szkoleniu z pamięci i wtedy wychodzi brak podpisu, protokołu albo zgodności programu z tym, co faktycznie przeprowadzono. Co z tym robimy: Program układamy pod role i dopiero z gotowym programem szukamy okna u operatora, a nie odwrotnie. Dokumentację prowadzimy równolegle z zajęciami: lista obecności, protokół walidacji efektów uczenia się i certyfikaty powstają tego samego dnia co szkolenie. Przed złożeniem rozliczenia sprawdzamy komplet wobec wymagań operatora. Co zostaje u was: komplet dokumentów rozliczeniowych zamknięty w dniu zakończenia szkolenia **Certyfikat mylony ze zgodnością** Po szkoleniu ktoś w dobrej wierze wpisuje w ankiecie klienckiej albo w ofercie przetargowej, że firma jest zgodna z AI Act. Certyfikat ze szkolenia nie mówi nic o klasyfikacji systemów, dokumentacji technicznej ani o nadzorze, więc rozjazd wychodzi przy pierwszym poważnym badaniu due diligence, czyli w najgorszym możliwym momencie: w trakcie transakcji albo postępowania. Co z tym robimy: W materiałach i w rejestrze zapisujemy wprost, co szkolenie pokrywa, a czego nie pokrywa. Do tego wydajemy jednostronicową notę zakresową napisaną językiem ankiety klienckiej, żeby osoba wypełniająca formularz miała gotowe i prawdziwe zdanie zamiast własnej interpretacji. Notę przeglądamy z waszym działem prawnym przed wydaniem. Co zostaje u was: nota zakresowa do ankiet klienckich i przetargów, przejrzana przez wasz dział prawny ### Co dostajecie - Rejestr przeszkolonych: imię i nazwisko, rola, data, program, wynik walidacji - Mapa ról z przypisanym wymaganym poziomem rozumienia AI - Program szkolenia dla każdej roli, z datą i zakresem, gotowy do okazania przy kontroli - Protokół walidacji efektów uczenia się: test wiedzy i zadanie praktyczne na waszym systemie - Imienne certyfikaty uczestnictwa - Lista narzędzi z funkcjami AI w rzeczywistym użyciu, z podziałem na program szkolenia i listę do klasyfikacji - Nota zakresowa: co szkolenie pokrywa, a czego nie pokrywa, do wykorzystania w ankietach klienckich - Komplet dokumentów rozliczeniowych, gdy szkolenie idzie ze środków publicznych ### Jak pracujemy 1. **1. Mapa ról i inwentaryzacja rzeczywistego użycia** (Tydzień 1): Ustalamy, kto ma kontakt z systemami AI i w jakiej roli oraz jakich narzędzi ludzie faktycznie używają, łącznie z funkcjami AI wbudowanymi w oprogramowanie kupione wcześniej. 2. **2. Program dla każdej roli i ścieżka finansowania** (Tydzień 1-2): Budujemy osobny program dla każdej grupy, na materiale z waszych systemów. Równolegle ustalamy, czy i z jakiego źródła szkolenie ma być dofinansowane oraz co to znaczy dla terminów i dokumentów. 3. **3. Szkolenia** (Tydzień 2-4, zależnie od liczby grup): Prowadzimy zajęcia grupami, każda po swoim programie. Grupy operacyjne i inżynierskie pracują na waszym środowisku, nie na przykładach z prezentacji. 4. **4. Walidacja efektów i wydanie artefaktów** (Tydzień 4): Sprawdzamy efekty testem i zadaniem praktycznym, wydajemy rejestr, protokół i certyfikaty, zamykamy dokumentację rozliczeniową. 5. **5. Przegląd** (Co 12 miesięcy albo po istotnej zmianie): Wracamy po zmianie systemów albo po roku: aktualizujemy mapę ról, dopisujemy nowe osoby i nowe narzędzia, odświeżamy program tam, gdzie zmienił się zakres. ### FAQ **Q: Czy art. 4 został przesunięty razem z resztą AI Act?** Nie. Pakiet omnibusowy z 2026 roku przesunął terminy zgodności dla systemów wysokiego ryzyka z załącznika III na 2 grudnia 2027, a dla systemów w produktach regulowanych na 2 sierpnia 2028. Art. 4 stosuje się nadal od 2 lutego 2025. Rozporządzenie 2026/1744 zmieniło natomiast od 27 lipca 2026 jego brzmienie: art. 4 wymaga środków wspierających rozwój kompetencji w zakresie AI, bez obowiązku zapewnienia określonego poziomu u poszczególnych osób. Nowe ustępy zobowiązują Komisję i państwa członkowskie do wspierania tych działań. **Q: Ile godzin szkolenia wystarczy?** Rozporządzenie nie podaje liczby godzin. Kryterium jest adekwatność programu do roli, wiedzy technicznej i kontekstu użycia systemu. W praktyce oznacza to od krótkiej sesji orientacyjnej dla zarządu po kilkudniowy program dla zespołu inżynierskiego, a decyduje o tym mapa ról, nie z góry przyjęty wymiar godzin. **Q: Kogo dokładnie trzeba przeszkolić?** Personel oraz inne osoby zajmujące się w waszym imieniu działaniem i wykorzystaniem systemów AI. Obejmuje to również osoby spoza etatu: kontraktorów, agencje i podwykonawców obsługujących wasze systemy. Zakres podmiotowy art. 4 jest szerszy niż lista pracowników. **Q: Czym udokumentujecie ten obowiązek przy kontroli?** Rejestrem przeszkolonych z datami i rolami, programem dla każdej roli, protokołem walidacji efektów uczenia się i imiennymi certyfikatami. To są dokumenty, które da się pokazać w ankiecie klienckiej, w przetargu i przy kontroli. Dowodem jest dokumentacja, nie samo odbycie szkolenia. **Q: Kto to kontroluje w Polsce?** Organem nadzoru rynku i pojedynczym punktem kontaktowym jest Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji, powołana ustawą z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003). Przepisy o trybie kontroli i o karach wchodzą w życie 28 października 2026. Odpowiedzialność za konkretne uchybienie ocenia radca prawny; my przygotowujemy dowody, na których taka ocena się opiera. **Q: Czy szkolenie da się rozliczyć z BUR albo z KFS?** Od 1 stycznia 2026 szkolenia finansowane przez urzędy pracy i z Krajowego Funduszu Szkoleniowego realizują podmioty wpisane do Bazy Usług Rozwojowych. KFS na 2026 rok wymienia AI wprost w priorytecie nr 3 Ministra do spraw pracy. Ten priorytet dotyczy kształcenia w związku z zastosowaniem w firmach nowych procesów, technologii i narzędzi pracy, zwłaszcza gdy stanowią one zagrożenie utratą pracy. We wniosku wyjaśnijcie więc, jak planowane szkolenie odpowiada temu priorytetowi. Warunki, limity i terminy ustala operator właściwy dla waszego województwa i sprawdzamy je razem z wami, zanim ustalimy zakres i termin. **Q: Czy po szkoleniu jesteśmy zgodni z AI Act?** Nie, i tak tego nie przedstawiamy. Art. 4 to jeden obowiązek. Zgodność wymaga co najmniej inwentaryzacji i klasyfikacji systemów, a dla systemów wysokiego ryzyka także dokumentacji technicznej, rejestrowania zdarzeń i nadzoru ze strony człowieka. Po szkoleniu dostajecie notę, która nazywa tę granicę wprost. ### Zakres tej strony Jesteśmy zespołem inżynierskim i szkoleniowym, nie kancelarią. Na tej stronie opisujemy, jak wykonać obowiązek i czym go udokumentować, a nie jak brzmi jego wykładnia dla waszej sytuacji. Wykładnię przepisu i ocenę odpowiedzialności podpisuje radca prawny: wasz albo nasz partner prawny. Daty i numery aktów podajemy razem ze źródłami, żeby dało się je sprawdzić bez pytania nas o zdanie. ### Powiązane - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/szkolenia-ai-z-dofinansowaniem - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zgodnosc-z-ai-act - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zasady-korzystania-z-ai ### Źródła - Ministerstwo Cyfryzacji: AI Act, co się zmieniło 2 sierpnia 2026 roku: https://www.gov.pl/web/cyfryzacja/ai-act--co-sie-zmienilo-2-sierpnia-2026-roku - Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003): https://eli.gov.pl/api/acts/DU/2026/1003/text/O/D20261003.pdf - Rozporządzenie (UE) 2024/1689 (AI Act), tekst w EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj - Zielona Linia: BUR zamiast RIS od 2026 roku: https://zielonalinia.gov.pl/bur-zamiast-ris-przygotuj-instytucje-szkoleniowa-na-nadejscie-2026-roku/ - Nabór FERS 1.3: Kompetencje z automatyzacji dla transformacji cyfrowej: https://www.funduszeunijne.gov.pl/nabory/13-kompetencje-z-automatyzacji-dla-transformacji-cyfrowej/ - Priorytety Ministra do spraw pracy wydatkowania KFS w roku 2026: https://wupbialystok.praca.gov.pl/rynek_pracy/kfs/-/asset_publisher/fRJeGax7dNIi/content/krajowy-fundusz-szkoleniowy-priorytety-na-rok-2026-1 - PARP: lista certyfikatów i akredytacji uprawniających do wpisu do BUR (stan na 21 stycznia 2026): https://serwis-uslugirozwojowe.parp.gov.pl/images/BUR_serwis_info/LISTY%20CERTYFIKATOW%20I%20UPRAWNIEN/Aktualna%20lista%20certyfikatow_akredytacji_stan%20na%2021.01.2026.pdf - Rozporządzenie (UE) 2026/1744 (omnibus cyfrowy), tekst w EUR-Lex: https://eur-lex.europa.eu/eli/reg/2026/1744/oj --- ## Rejestr i klasyfikacja systemów AI: ustawa z 3 lipca 2026 i kalendarz KRiBSI **URL:** https://23minds.com/pl/przewodniki/rejestr-i-klasyfikacja-systemow-ai **Adres kanoniczny (dla tej strony kanoniczny jest polski):** https://23minds.com/pl/przewodniki/rejestr-i-klasyfikacja-systemow-ai > Zanim ktokolwiek zapyta was o zgodność, trzeba umieć odpowiedzieć na dwa pytania: które z waszych narzędzi są systemami AI i kto jest przy nich dostawcą, a kto podmiotem stosującym. Rejestr jest odpowiedzią na oba i to on decyduje, ile pracy zostanie później. ### Podsumowanie 23Minds buduje rejestry systemów AI i przeprowadza ich klasyfikację ryzyka dla firm i instytucji działających w Polsce. Podstawą krajową jest ustawa z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003), która weszła w życie 11 sierpnia 2026. Art. 8-18 oraz rozdziały 3-5, 8 i 9, w których znajduje się tryb kontroli i przepisy o karach, wchodzą w życie 28 października 2026. Organem nadzoru rynku i pojedynczym punktem kontaktowym jest Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji. 23Minds wykonuje inżynierską część tej pracy: znajduje systemy AI również tam, gdzie zostały wbudowane w kupione oprogramowanie, opisuje je w rejestrze razem z uzasadnieniem klasyfikacji i wpina rejestr w procesy, dzięki którym nie zestarzeje się po kwartale. Wykładnia i podpis pod klasyfikacją zostają przy radcy prawnym. ### Dla kogo to jest - Firmy, które kupiły albo zbudowały narzędzia z funkcjami AI i nie mają jednej listy tych systemów - Zespoły produktowe, których funkcja AI została właśnie zakwestionowana w ankiecie od klienta - Software house'y i integratorzy, którzy muszą powiedzieć klientowi, w jakiej roli występują - Urzędy i samorządy, w których urzędnicy korzystają z generatywnej AI szybciej, niż powstają zasady - Compliance, CISO i CTO, którzy potrzebują artefaktu do podpisania, a nie prezentacji ### Co weszło w życie i kiedy Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji została ogłoszona 27 lipca 2026 (Dz.U. 2026 poz. 1003) i weszła w życie 11 sierpnia 2026. Art. 8-18 oraz rozdziały 3-5, 8 i 9 wchodzą w życie później, 28 października 2026. To rozróżnienie ma znaczenie praktyczne, bo właśnie w tej późniejszej grupie znajduje się tryb kontroli i przepisy o karach. Art. 5 ust. 1-2 ustanawia Komisję Rozwoju i Bezpieczeństwa Sztucznej Inteligencji organem nadzoru rynku w rozumieniu art. 70 ust. 1 rozporządzenia (UE) 2024/1689 oraz pojedynczym punktem kontaktowym. Przewodniczącą Komisji powołał Sejm za zgodą Senatu, wyrażoną 24 września 2026. Komisja ma rozpocząć pracę w listopadzie 2026. Ustawa przewiduje również piaskownice regulacyjne, a mikro, mali i średni przedsiębiorcy mogą w nich uczestniczyć nieodpłatnie. | Data | Co się zmienia | Co to znaczy w praktyce | | --- | --- | --- | | 27 lipca 2026 | Ogłoszenie ustawy w Dzienniku Ustaw (poz. 1003) | Treść jest publiczna i można na niej pracować | | 11 sierpnia 2026 | Wejście w życie ustawy, poza wskazanymi przepisami | Ramy krajowe obowiązują, organ jest ustanowiony | | 24 września 2026 | Zgoda Senatu na powołanie przewodniczącej Komisji | Pojawia się adresat zgłoszeń i pytań | | 28 października 2026 | Wejście w życie art. 8-18 oraz rozdziałów 3-5, 8 i 9 | Zaczyna działać tryb kontroli i przepisy o karach | | listopad 2026 | Rozpoczęcie pracy Komisji | Nadzór rynku staje się operacyjny | ### Czy wasze narzędzie jest systemem AI Nikt nie przyjdzie i nie powie wam, że dany system podlega przepisom. Każdy podmiot ocenia to samodzielnie, a ocena musi dać się odtworzyć, bo to od niej zaczyna się rozmowa przy kontroli, w ankiecie klienckiej i w badaniu due diligence. Oceniamy cechy techniczne systemu, a nie to, jak nazywa go dostawca w materiałach handlowych. Znaczenie ma to, czy system wnioskuje z danych wejściowych i jak dużą ma autonomię. Liczy się też, czy jego wyniki, na przykład rekomendacje albo decyzje dotyczące ludzi, mogą wpływać na środowisko fizyczne lub wirtualne. Zdolność adaptacji po wdrożeniu definicja wymienia jako cechę możliwą, a nie konieczną. Najwięcej sporów powstaje tam, gdzie łatwo powiedzieć, że to tylko automatyzacja: scoring i ranking, predykcja używana do typowania spraw do kontroli, klasyfikacja dokumentów, generowanie odpowiedzi w obsłudze klienta, sortowanie kandydatów. Publicznie opisywane spory o kwalifikację takich systemów pokazują, że rozstrzyga się to na faktach technicznych, więc te fakty trzeba mieć spisane, zanim ktoś zapyta. - Reguły napisane ręcznie a model wytrenowany na danych to dwie różne odpowiedzi, więc trzeba wiedzieć, co naprawdę siedzi w produkcie - System kupiony, w którym dostawca dołożył funkcję AI w aktualizacji, jest waszym systemem w rozumieniu obowiązków podmiotu stosującego - Ta sama technologia w dwóch zastosowaniach może mieć dwie różne klasy ryzyka, bo decyduje przeznaczenie, nie algorytm - Przypadek graniczny opisujemy jako graniczny i kierujemy do radcy, zamiast rozstrzygać go po cichu na korzyść wygodniejszej odpowiedzi ### Jak zrobić inwentaryzację, która się obroni Inwentaryzacja zrobiona przez wysłanie ankiety do zespołów kończy się listą tego, co ludzie pamiętają. Zbieramy z czterech źródeł naraz i porównujemy wyniki, bo dopiero rozbieżności między nimi pokazują, czego brakuje. Poniżej pola, które musi mieć wpis, żeby dało się go obronić bez obecności osoby, która go tworzyła. - Co zbudowaliście sami: repozytoria, wywołania API modeli, usługi z wbudowaną integracją modelu - Co kupiliście świadomie jako narzędzie AI: umowy, faktury, aneksy do umów powierzenia - Co dostaliście po cichu: funkcje AI dołożone przez dostawców w aktualizacjach istniejącego oprogramowania - Czego ludzie używają sami: aplikacje widoczne w logowaniu SSO i w wydatkach na kartach służbowych | Pole rejestru | Po co jest | | --- | --- | | Nazwa i właściciel biznesowy | Jest osoba, która odpowiada za wpis i za jego aktualność | | Przeznaczenie | Klasa ryzyka wynika z przeznaczenia, nie z technologii | | Dane wejściowe i ich źródło | Podstawa oceny wpływu na osoby i wymagań wobec danych | | Model i dostawca, razem z wersją | Bez wersji nie da się odtworzyć, na czym oparto ocenę | | Wasza rola: dostawca albo podmiot stosujący | Od roli zależy zestaw obowiązków | | Klasa ryzyka i uzasadnienie | Sama klasa bez uzasadnienia jest nie do obrony | | Nadzór ze strony człowieka: kto i w którym momencie | Odróżnia deklarację od działającego mechanizmu | | Data wpisu, data przeglądu, osoba | Pokazuje, że rejestr żyje, a nie powstał raz pod audyt | ### Dostawca czy podmiot stosujący Rola decyduje o zestawie obowiązków i bywa częstszym źródłem nieporozumień niż sama klasa ryzyka. Firma, która wdraża kupiony system, występuje zwykle jako podmiot stosujący, ale może stać się dostawcą, jeżeli oznacza system własną nazwą lub znakiem towarowym, istotnie go modyfikuje albo zmienia jego przeznaczenie na takie, którego sam dostawca nie przewidział. To rozróżnienie sprawdzamy dla każdego wpisu w rejestrze i zapisujemy razem z faktami, na których się opiera. Ostateczną kwalifikację prawną potwierdza radca, bo od niej zależy lista obowiązków, które trzeba potem wykonać. ### Gdzie to się psuje i co z tym robimy **Rejestr powstaje w arkuszu i umiera po kwartale** Inwentaryzacja zrobiona jednorazowo pod audyt albo pod ankietę klienta trafia do arkusza i nie ma ani właściciela, ani punktu, w którym ktoś musi ją zaktualizować. Systemy zmieniają się szybciej niż arkusz: dostawca włącza funkcję AI w aktualizacji, zespół podmienia model na nowszy, ktoś kupuje narzędzie na kartę służbową. Po dwóch kwartałach rejestr opisuje stan, którego już nie ma. Jest wtedy gorszy niż jego brak, bo daje poczucie kontroli bez pokrycia. Co z tym robimy: Wpinamy rejestr w procesy, które i tak się dzieją: zakup narzędzia, wdrożenie, zmiana dostawcy i zmiana modelu dostają pole obowiązkowe z odsyłaczem do wpisu. Każdy wpis ma właściciela z imienia i nazwiska. Do tego ustawiamy kwartalny przegląd, w którym rejestr porównuje się z listą aplikacji z logowania SSO i z wydatkami, a różnice trafiają na listę do wyjaśnienia. Co zostaje u was: rejestr z właścicielami, procedura aktualizacji wpięta w zakupy i wdrożenia oraz kwartalna lista różnic **Klasyfikacja bez uzasadnienia** W kolumnie z klasą ryzyka stoi wartość, ale nie ma zapisu, na jakiej podstawie ją przyjęto. Osoba, która to rozstrzygnęła, zmieniła stanowisko albo firmę. Przy pierwszym pytaniu kontrolera, klienta albo kupującego w due diligence nikt nie odtworzy toku rozumowania, więc całą klasyfikację robi się od nowa, tym razem pod presją czasu. Co z tym robimy: Każdy wpis dostaje uzasadnienie z powołaniem na przepis i na konkretne fakty o systemie: przeznaczenie, dane, autonomię i wpływ na osoby. Zapisujemy datę i osobę. Uzasadnienia przechodzimy razem z waszym radcą prawnym i utrwalamy wynik tego przeglądu obok wpisu, a nie w czyjejś skrzynce pocztowej. Co zostaje u was: uzasadnienie klasyfikacji dla każdego systemu, w formie gotowej do przeglądu i podpisu przez prawnika **AI wbudowana w kupione narzędzie zostaje poza rejestrem** Inwentaryzacja pyta zespoły, co zbudowały, a nie pyta dostawców, co dołożyli. Funkcje AI wchodzą do systemu rekrutacyjnego, obsługi zgłoszeń i CRM przy zwykłej aktualizacji, bez żadnej decyzji po waszej stronie. To właśnie przy nich stoi zestaw obowiązków podmiotu stosującego, a w rejestrze ich nie ma, bo nikt nie uznał aktualizacji za wdrożenie AI. Co z tym robimy: Wysyłamy dostawcom konkretne pytanie o funkcje AI w używanej przez was wersji i o to, co planują dołożyć; wzór pytania zostaje u was do ponownego użycia. Równolegle czytamy changelogi i aneksy do umów powierzenia oraz porównujemy listę aplikacji z SSO z rejestrem. Odpowiedzi i daty sprawdzenia zapisujemy przy wpisach, więc następnym razem widać, co jest świeże, a co wymaga ponowienia. Co zostaje u was: lista dostawców z odpowiedziami i datami oraz wzór pytania do ponownego użycia **Kwalifikacja rozstrzygana życzeniowo** Uznanie systemu za zwykłą automatyzację jest tańsze i szybsze, więc opis produktu zaczyna dopasowywać się do pożądanego wyniku. Rzecz w tym, że kwalifikację ocenia się na faktach technicznych, a te są zapisane w kodzie, w umowie z dostawcą i w tym, co system realnie robi z danymi. Rozjazd między opisem a faktami wychodzi dokładnie wtedy, kiedy jest najdroższy. Co z tym robimy: Kwalifikację prowadzimy na faktach: co jest w kodzie i w konfiguracji, jakie dane wchodzą, jak duża jest autonomia i co dzieje się z wynikiem. Fakty spisujemy przy wpisie razem ze źródłem. Przypadki, w których fakty nie rozstrzygają, oznaczamy jako sporne i przekazujemy radcy z gotowym pytaniem, zamiast rozstrzygać je samodzielnie. Co zostaje u was: lista przypadków granicznych z opisem faktów i pytaniem sformułowanym dla radcy prawnego **Kalendarz czytany jako jedna data** Zdanie o tym, że ustawa weszła w życie 11 sierpnia, brzmi jak zamknięcie tematu, więc plan pracy powstaje pod tę jedną datę. Tymczasem przepisy o trybie kontroli i o karach wchodzą 28 października, a organ staje się operacyjny jeszcze później. Najtwardsza część harmonogramu zostaje na koniec, kiedy nie ma już miejsca na przesunięcie. Co z tym robimy: Plan pracy układamy pod obie daty i pod moment, w którym organ zaczyna działać, z listą tego, co musi być gotowe przed każdą z nich. Harmonogram ma właścicieli i statusy, więc widać na nim, co jest zrobione, a co dopiero zaplanowane. Przechodzimy przez niego z wami raz w miesiącu do końca roku. Co zostaje u was: harmonogram z podziałem na obie daty wejścia w życie, z właścicielami i statusem ### Co dostajecie - Rejestr systemów AI z właścicielem, przeznaczeniem, danymi, modelem, dostawcą i wersją - Uzasadnienie klasyfikacji dla każdego systemu, gotowe do przeglądu prawnego - Ustalenie roli, dostawca albo podmiot stosujący, dla każdego wpisu, razem z faktami - Procedura aktualizacji rejestru wpięta w zakupy, wdrożenia i zmiany dostawcy - Lista dostawców z odpowiedziami na pytania o funkcje AI oraz wzór pytania do ponownego użycia - Lista przypadków granicznych z pytaniami sformułowanymi dla radcy prawnego - Harmonogram z podziałem na 11 sierpnia i 28 października 2026 ### Jak pracujemy 1. **1. Zbiórka z czterech źródeł** (Tydzień 1): Repozytoria i wywołania API, umowy i faktury, changelogi dostawców, logowanie SSO i wydatki. Porównujemy wyniki, a rozbieżności między nimi wyznaczają dalszą pracę. 2. **2. Rejestr i pierwsza klasyfikacja** (Tydzień 1-2): Opisujemy każdy system w pełnym zestawie pól, przypisujemy rolę i klasę ryzyka razem z uzasadnieniem opartym na faktach. 3. **3. Przypadki graniczne i przegląd prawny** (Tydzień 2-3): Oddzielamy to, co rozstrzygają fakty, od tego, co wymaga wykładni. Przygotowujemy pytania i przechodzimy przez nie z waszym radcą albo z naszym partnerem prawnym. 4. **4. Wpięcie w procesy i przekazanie** (Tydzień 3-4): Rejestr dostaje właścicieli i procedurę aktualizacji, a harmonogram terminów trafia do osób, które za nie odpowiadają. Przekazujemy komplet i omawiamy go z kierownictwem. 5. **5. Przegląd kwartalny** (Co kwartał): Porównujemy rejestr z rzeczywistością: nowe aplikacje w SSO, aktualizacje dostawców, zmiany modeli. Różnice wyjaśniamy i dopisujemy. ### FAQ **Q: Od kiedy grożą kary za systemy AI w Polsce?** Ustawa z 3 lipca 2026 (Dz.U. 2026 poz. 1003) weszła w życie 11 sierpnia 2026, ale art. 8-18 oraz rozdziały 3-5, 8 i 9, w których znajduje się tryb kontroli i przepisy o karach, wchodzą w życie 28 października 2026. Wymiar odpowiedzialności w konkretnej sprawie ocenia prawnik; my przygotowujemy dokumentację, na której taka ocena się opiera. **Q: Kto jest organem nadzoru?** Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji, ustanowiona organem nadzoru rynku w rozumieniu art. 70 ust. 1 rozporządzenia (UE) 2024/1689 i pojedynczym punktem kontaktowym. Przewodniczącą powołał Sejm za zgodą Senatu, wyrażoną 24 września 2026. Komisja ma rozpocząć pracę w listopadzie 2026. **Q: Czy narzędzia kupione też trzeba wpisać do rejestru?** Tak. Obowiązki podmiotu stosującego dotyczą również systemów kupionych, w tym funkcji AI dołożonych przez dostawcę w aktualizacji oprogramowania, którego używacie od lat. To najczęściej pomijana część rejestru i zwykle właśnie tam znajdujemy najwięcej wpisów. **Q: Czy rejestr trzeba komuś zgłaszać?** Rejestr jest przede wszystkim waszym narzędziem: bez niego nie da się odpowiedzieć na pytanie o klasyfikację ani wykonać pozostałych obowiązków. Zakres ewentualnych obowiązków zgłoszeniowych zależy od klasy systemu i od waszej roli, więc ustalamy go dla konkretnych wpisów i potwierdzamy z radcą prawnym, zamiast podawać ogólną regułę. **Q: Ile trwa inwentaryzacja?** Dla organizacji z kilkunastoma systemami zwykle trzy do czterech tygodni od zbiórki danych do przekazania rejestru z uzasadnieniami. Najwięcej czasu zajmuje nie opisanie systemów, tylko dotarcie do tych, o których nikt nie pamięta, więc harmonogram zależy od tego, jak szybko dostajemy dostęp do logowania SSO, umów i changelogów. **Q: Czym to się różni od audytu zgodności z AI Act?** Rejestr i klasyfikacja są pierwszym krokiem i odpowiadają na pytanie, co w ogóle podlega ocenie. Audyt idzie dalej: sprawdza wykonanie obowiązków dla systemów już sklasyfikowanych i kończy się analizą luk oraz planem naprawczym. Jedno bez drugiego nie ma sensu, ale to dwa różne zakresy i dwie różne wyceny. **Q: Czy piaskownica regulacyjna kosztuje?** Ustawa przewiduje piaskownice regulacyjne, a mikro, mali i średni przedsiębiorcy uczestniczą w nich nieodpłatnie (art. 93 ust. 1). Warunki uczestnictwa i tryb naboru określa rozdział 7 ustawy, obowiązujący od 11 sierpnia 2026, więc sprawdzamy je w aktualnym brzmieniu przy składaniu wniosku. ### Zakres tej strony Jesteśmy zespołem inżynierskim, nie kancelarią. Budujemy rejestr, zbieramy fakty i przygotowujemy uzasadnienia w formie gotowej do przeglądu, ale kwalifikację prawną systemu i ocenę obowiązków podpisuje radca prawny: wasz albo nasz partner prawny. Przypadki, w których fakty nie rozstrzygają, oznaczamy jako sporne, zamiast rozstrzygać je po cichu. ### Powiązane - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zgodnosc-z-ai-act - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zasady-korzystania-z-ai - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/szkolenia-ai-z-dofinansowaniem ### Źródła - Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003), tekst aktu: https://eli.gov.pl/api/acts/DU/2026/1003/text/O/D20261003.pdf - Ministerstwo Cyfryzacji: ustawa o systemach AI, bezpieczny rozwój sztucznej inteligencji w Polsce: https://www.gov.pl/web/cyfryzacja/ustawa-o-systemach-ai--bezpieczny-rozwoj-sztucznej-inteligencji-w-polsce - Rozporządzenie (UE) 2024/1689 (AI Act), tekst w EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj - prawo.pl: AI Act wchodzi w życie, urzędy nie wiedzą, czy korzystają ze sztucznej inteligencji: https://www.prawo.pl/samorzad/ai-act-wchodzi-w-zycie-urzedy-nie-wiedza-czy-korzystaja-ze-sztucznej-inteligencji,1547762.html - Przewodnik po sztucznej inteligencji dla administracji publicznej (Ministerstwo Cyfryzacji, marzec 2026): https://ai.gov.pl/media/2026/03/Przewodnik-po-sztucznej-inteligencji-dla-administracji-publicznej-1.pdf - Senat RP: 65. posiedzenie Senatu, 24 września 2026, zgoda na powołanie przewodniczącej Komisji Rozwoju i Bezpieczeństwa Sztucznej Inteligencji: https://www.senat.gov.pl/aktualnoscilista/art,17779,65-posiedzenie-senatu-drugi-dzien.html - Komisja Europejska: wytyczne w sprawie definicji systemu AI z rozporządzenia 2024/1689, C(2025) 5053 final: https://ec.europa.eu/newsroom/dae/redirection/document/112455 --- ## Obowiązki przejrzystości z art. 50 AI Act: co obowiązuje od 2 sierpnia 2026 **URL:** https://23minds.com/pl/przewodniki/obowiazek-przejrzystosci-artykul-50 **Adres kanoniczny (dla tej strony kanoniczny jest polski):** https://23minds.com/pl/przewodniki/obowiazek-przejrzystosci-artykul-50 > Przesunięcie terminów zgodności z AI Act dotyczy systemów wysokiego ryzyka. Obowiązki przejrzystości z art. 50 weszły w pierwotnym terminie, 2 sierpnia 2026, a dostawcy systemów generatywnych wprowadzonych do obrotu przed tą datą mają czas do 2 grudnia 2026 na dostosowanie oznaczania treści. ### Podsumowanie 23Minds wdraża obowiązki przejrzystości z art. 50 rozporządzenia (UE) 2024/1689 w produktach cyfrowych i w procesach publikacji treści. Obowiązki te stosuje się od 2 sierpnia 2026 i nie objęło ich przesunięcie terminów, które rozporządzenie (UE) 2026/1744 wprowadziło dla systemów wysokiego ryzyka z załącznika III oraz dla systemów AI w produktach regulowanych. Wdrożenie przekłada trzy obowiązki na czynności inżynierskie: poinformowanie użytkownika, że rozmawia z systemem AI, maszynowo odczytywalne oznaczanie treści generowanych oraz informowanie odbiorcy, że deepfake jest sztucznie wygenerowany lub zmanipulowany, w formie, którą zobaczy albo usłyszy. Test sprawdza oznaczenia na końcu ścieżki publikacji zamiast w narzędziu i powtarza tę weryfikację przy każdym wdrożeniu. Wykładnię przepisu podpisuje radca prawny. ### Dla kogo to jest - Zespoły produktowe z czatem, asystentem albo kanałem głosowym obsługiwanym przez model - Redakcje i zespoły marketingu publikujące grafiki, wideo i teksty tworzone z udziałem AI - Firmy, które wdrożyły asystenta w kanale obsługi klienta u siebie albo u partnera - Osoby odpowiedzialne za zgodność produktu, które dostały z rynku sprzeczne komunikaty o terminach ### Co przesunięto, a czego nie Rozporządzenie (UE) 2026/1744, znane jako omnibus cyfrowy, weszło w życie 27 lipca 2026 i przesunęło terminy zgodności dla systemów wysokiego ryzyka. Obowiązków przejrzystości z art. 50 nie przesunęło. Rozporządzenie (UE) 2026/1744 wprowadziło też okres przejściowy: dostawcy systemów generatywnych wprowadzonych do obrotu lub oddanych do użytku przed 2 sierpnia 2026 mają czas do 2 grudnia 2026 na dostosowanie ich do technicznych obowiązków oznaczania treści. | Obowiązek | Termin pierwotny | Stan po zmianie | | --- | --- | --- | | Kompetencje w zakresie AI (art. 4) | 2 lutego 2025 | Bez zmian, obowiązuje | | Obowiązki przejrzystości (art. 50) | 2 sierpnia 2026 | Bez zmian, obowiązuje | | Systemy wysokiego ryzyka z załącznika III | 2 sierpnia 2026 | Przesunięte na 2 grudnia 2027 | | Systemy AI w produktach regulowanych (załącznik I) | 2 sierpnia 2027 | Przesunięte na 2 sierpnia 2028 | | Oznaczanie treści w systemach generatywnych wprowadzonych do obrotu przed 2 sierpnia 2026 | 2 sierpnia 2026 | Okres przejściowy do 2 grudnia 2026 | ### Trzy obowiązki przełożone na czynności inżynierskie Art. 50 opisuje wynik, a nie implementację. Poniżej to, co z niego wynika dla produktu, w podziale na miejsce w interfejsie, sposób wykonania i sposób sprawdzenia. | Obowiązek | Gdzie to widać w produkcie | Jak to wykonać | Jak to sprawdzić | | --- | --- | --- | --- | | Poinformowanie, że rozmówcą jest system AI | Pierwsza wiadomość w rozmowie i trwała etykieta w nagłówku okna, na każdym wejściu: widget, kanał głosowy, poczta, integracja u partnera | Komunikat w warstwie interfejsu, nie w regulaminie; treść jasna i zrozumiała dla osoby, która nie zna waszego produktu | Przejście przez wszystkie punkty wejścia ze zrzutem ekranu z każdego z nich | | Maszynowo odczytywalne oznaczenie treści generowanej | Plik wychodzący z waszego systemu i ten sam plik pobrany z produkcyjnego adresu | Content Credentials w standardzie C2PA albo metadane w polach XMP i IPTC, plus wpis w rejestrze wygenerowanych zasobów | Pobranie opublikowanego zasobu i odczyt oznaczenia czytnikiem, a nie sprawdzenie pliku w narzędziu | | Ujawnienie, że treści deepfake zostały sztucznie wygenerowane lub zmanipulowane | Miejsce publikacji: strona, materiał wideo, post, kreacja reklamowa | Oznaczenie, które odbiorca zobaczy albo usłyszy, w samym materiale albo bezpośrednio przy nim, niezależne od metadanych | Przegląd opublikowanych materiałów kanał po kanale, z listą i datą | ### Co zrobić z treścią już opublikowaną Materiały wygenerowane i udostępnione przed 2 sierpnia 2026 nie wymagają oznaczenia wstecz. Dla systemów generatywnych wprowadzonych do obrotu przed tą datą terminem dostosowania jest 2 grudnia 2026. Wsteczne oznaczanie starszych materiałów jest więc waszą decyzją, a nie wymogiem. Bywa uzasadnione tam, gdzie materiał może zostać wzięty za zapis rzeczywistego zdarzenia. Kolejność pracy: najpierw inwentaryzacja, potem priorytety, na końcu decyzja zapisana tam, gdzie da się ją później odnaleźć. - Inwentaryzacja: co zostało wygenerowane, kiedy, jakim modelem i gdzie leży - Priorytet dla materiałów z wizerunkiem osoby i dla wszystkiego, co może zostać wzięte za zapis rzeczywistego zdarzenia - Ponowne oznaczenie tam, gdzie kanał na to pozwala i gdzie sami uznacie to za potrzebne, z zachowaniem adresu - Dla zasobów, których nie da się albo nie warto oznaczać wstecz: zapisana decyzja z uzasadnieniem i datą, żeby nie wracać do tego pytania co kwartał - Rejestr wygenerowanych zasobów z sumą kontrolną, żeby przy następnej zmianie nie zaczynać od zera ### Gdzie to się psuje i co z tym robimy **Oznaczenie maszynowe ginie po drodze** Content Credentials i metadane XMP przeżywają eksport z narzędzia, ale kasuje je pierwszy element ścieżki publikacji, który przepuszcza plik przez konwersję: sieć dostarczania treści przerabiająca obrazy na WebP, kompresja w systemie zarządzania treścią albo upload na platformę społecznościową. Zespół widzi poprawnie oznaczony plik w repozytorium i uznaje temat za zamknięty, choć na produkcji oznaczenia już nie ma. Co z tym robimy: Sprawdzamy oznaczenie na końcu ścieżki, czyli na zasobie pobranym z produkcyjnego adresu, a nie na pliku w narzędziu. Zostawiamy test, który to powtarza przy każdym wdrożeniu i zgłasza brak. Tam, gdzie kanał kasuje metadane i nie da się tego zmienić, dokładamy oznaczenie widoczne dla człowieka i zapisujemy tę decyzję w rejestrze zasobów. Co zostaje u was: raport zgodności oznaczeń kanał po kanale oraz test weryfikujący wpięty w proces wdrożeniowy **Komunikat o rozmowie z maszyną schowany w regulaminie** Informacja o tym, że użytkownik rozmawia z asystentem, trafia do polityki prywatności albo do dymku pod ikoną, bo zespół nie chce psuć pierwszego wrażenia. Wymóg mówi o informacji podanej w jasny i wyraźny sposób najpóźniej przy pierwszej interakcji, więc o jego spełnieniu decyduje miejsce, w którym ta informacja się pojawia. Do tego najczęściej brakuje jej na tym wejściu, o którym nikt nie pamięta: w integracji u partnera, w kanale głosowym albo w automatycznej odpowiedzi na pocztę. Co z tym robimy: Umieszczamy komunikat w pierwszej wiadomości i jako trwałą etykietę w nagłówku rozmowy, a potem przechodzimy wszystkie wejścia do systemu, łącznie z tymi u partnerów. Każde wejście dostaje status i zrzut ekranu. Lista wejść zostaje u was, więc przy dodaniu nowego kanału wiadomo, co trzeba sprawdzić. Co zostaje u was: inwentarz punktów wejścia ze statusem i zrzutem ekranu dla każdego **Napis na grafice zamiast oznaczenia treści** Zespół dokłada podpis w rogu obrazu i traktuje to jako spełnienie wymogu maszynowej odczytywalności. Napis przycina pierwszy kadr wideo albo miniatura w kanale społecznościowym, a maszynowo nikt go nie odczyta. W drugą stronę działa to tak samo: metadane w pliku nie są oznaczeniem, które człowiek zobaczy albo usłyszy, więc przy deepfake'ach same nie wystarczą. Co z tym robimy: Rozdzielamy dwa wymogi i realizujemy oba, każdy właściwą techniką: oznaczenie widoczne dla człowieka i oznaczenie odczytywalne maszynowo. Dla każdego typu treści, czyli obrazu, wideo, dźwięku i tekstu, spisujemy, co dokładnie ma się pojawić i gdzie. Wynik sprawdzamy czytnikiem C2PA i przeglądem wizualnym, osobno. Co zostaje u was: specyfikacja oznaczania dla każdego typu treści, z wynikiem weryfikacji obiema metodami **Dostawca deklaruje oznaczanie, nikt tego nie sprawdził** Dokumentacja dostawcy modelu mówi o znaku wodnym albo o Content Credentials, więc temat schodzi z listy. Tymczasem oznaczenie bywa zależne od wersji modelu, od trybu wywołania i od tego, którą końcówką API się posługujecie, a wasza integracja mogła powstać przed tą funkcją albo ją omijać. Deklaracja jest w dokumentacji dostawcy, a nie w waszym pliku. Co z tym robimy: Bierzemy próbki z waszej realnej integracji, dla każdego modelu i trybu wywołania, a potem sprawdzamy, co faktycznie wychodzi. Różnice wobec dokumentacji zapisujemy z datą i wersją modelu i eskalujemy do dostawcy. To, czego dostawca nie dodaje, oznaczamy po waszej stronie, zamiast czekać na jego wydanie. Co zostaje u was: wyniki próbkowania z datą, wersją modelu i trybem wywołania **Rynek mówi o przesunięciu, więc zespół odkłada wszystko** Nagłówek o przesunięciu AI Act dotyczy systemów wysokiego ryzyka, ale w planie pracy ląduje jako jedno zdanie: mamy czas do 2027 roku. Obowiązki przejrzystości weszły w terminie i dotyczą produktów, które są na rynku teraz. Plan powstaje na podstawie nagłówka, nie na podstawie tabeli terminów, a różnicę widać dopiero wtedy, gdy ktoś z zewnątrz zapyta o konkretną funkcję. Co z tym robimy: Dajemy tabelę terminów z podstawami prawnymi i mapujemy ją na wasze systemy: dla każdego z nich wprost piszemy, co obowiązuje teraz, a co dopiero będzie obowiązywać. Zestawienie mieści się na jednej stronie, więc da się je pokazać zarządowi bez tłumaczenia rozporządzenia. Aktualizujemy je przy każdej zmianie stanu prawnego. Co zostaje u was: jednostronicowe zestawienie terminów dla każdego systemu, z podstawą prawną przy każdej pozycji ### Co dostajecie - Inwentarz punktów, w których użytkownik styka się z systemem AI, ze statusem i zrzutem ekranu - Specyfikacja oznaczania dla każdego typu treści: obraz, wideo, dźwięk, tekst - Test weryfikujący oznaczenie na opublikowanym zasobie, wpięty w wasz proces wdrożeniowy - Rejestr wygenerowanych zasobów z modelem, wersją, datą i sumą kontrolną - Zestawienie terminów dla każdego systemu: co przesunięto, czego nie i co z tego wynika dla was - Lista pytań do radcy prawnego tam, gdzie decyzja jest wykładnią, a nie inżynierią ### Jak pracujemy 1. **1. Inwentaryzacja miejsc styku i zasobów** (Dni 1-3): Przechodzimy wszystkie wejścia do rozmowy z systemem oraz wszystkie kanały publikacji treści generowanych. Wynikiem jest lista ze statusem, a nie opinia. 2. **2. Specyfikacja i poprawki** (Tydzień 1-2): Ustalamy, co ma stanąć w interfejsie i jak oznaczane są poszczególne typy treści, a potem wdrażamy zmiany razem z waszym zespołem. 3. **3. Weryfikacja na produkcji** (Tydzień 2): Sprawdzamy oznaczenia na zasobach pobranych z produkcyjnych adresów kanał po kanale i zostawiamy test, który powtarza to przy każdym wdrożeniu. 4. **4. Przekazanie i przegląd przy zmianie modelu** (Tydzień 2-3, potem przy każdej zmianie modelu): Oddajemy specyfikację, rejestr i test. Wracamy przy podmianie modelu albo dostawcy, bo to moment, w którym oznaczenia najczęściej cicho znikają. ### FAQ **Q: Czy art. 50 też został przesunięty?** Nie. Rozporządzenie (UE) 2026/1744 weszło w życie 27 lipca 2026 i przesunęło terminy dla systemów wysokiego ryzyka z załącznika III na 2 grudnia 2027, a dla systemów AI w produktach regulowanych na 2 sierpnia 2028. Obowiązki przejrzystości z art. 50 weszły w pierwotnym terminie, 2 sierpnia 2026. Jest natomiast jeden okres przejściowy: dostawcy systemów generatywnych wprowadzonych do obrotu przed 2 sierpnia 2026 mają czas do 2 grudnia 2026 na dostosowanie się do technicznych wymogów oznaczania treści. **Q: Czy czat na naszej stronie wymaga komunikatu?** Jeżeli użytkownik wchodzi w interakcję z systemem AI, trzeba go o tym poinformować w jasny i wyraźny sposób, chyba że jest to oczywiste dla osoby dostatecznie poinformowanej, uważnej i ostrożnej, z uwzględnieniem okoliczności i kontekstu. W praktyce oznacza to komunikat w pierwszej wiadomości i trwałą etykietę w interfejsie, a nie zapis w regulaminie. Dotyczy każdego wejścia do rozmowy, także tego uruchamianego u partnera. **Q: Co znaczy oznaczenie maszynowo odczytywalne?** Oznaczenie, które maszyna potrafi odczytać z samego zasobu, na przykład Content Credentials w standardzie C2PA albo metadane w polach XMP i IPTC. Napis na grafice nim nie jest. Trzeba też liczyć się z tym, że część kanałów publikacji usuwa metadane, więc oznaczenie sprawdza się na zasobie opublikowanym, a nie na pliku w narzędziu. **Q: Czy trzeba oznaczać teksty pisane z pomocą AI na firmowym blogu?** Obowiązek dotyczy tekstu publikowanego w celu informowania opinii publicznej o sprawach leżących w interesie publicznym, a jego zasięg wobec materiałów czysto marketingowych bywa różnie odczytywany. To jest miejsce na wykładnię radcy, nie na naszą deklarację. Praktycznie rekomendujemy prowadzenie rejestru wygenerowanych zasobów niezależnie od tego, jak wypadnie ta ocena, bo bez rejestru każda późniejsza decyzja kosztuje wielokrotnie więcej. **Q: A materiały opublikowane wcześniej?** Materiały wygenerowane i udostępnione przed 2 sierpnia 2026 nie wymagają oznaczenia wstecz. Osobną sprawą są systemy generatywne wprowadzone do obrotu przed tą datą: ich dostawcy mają czas do 2 grudnia 2026 na dostosowanie się do technicznych wymogów oznaczania. O wstecznym oznaczaniu starszych materiałów decydujecie sami. Warto je rozważyć tam, gdzie materiał może zostać odebrany jako zapis rzeczywistego zdarzenia. Taką decyzję zapisujemy razem z uzasadnieniem i datą. **Q: Czy dostawca modelu nie robi tego za nas?** Część dostawców dodaje oznaczenia po swojej stronie, ale zależy to od modelu, wersji i trybu wywołania, a odpowiedzialność zostaje przy was. Sprawdzamy próbki z waszej realnej integracji dla każdego modelu i trybu. To, czego dostawca nie dodaje, oznaczamy po waszej stronie. **Q: Kto to egzekwuje w Polsce?** Komisja Rozwoju i Bezpieczeństwa Sztucznej Inteligencji jako organ nadzoru rynku i pojedynczy punkt kontaktowy, ustanowiona ustawą z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003). Przepisy o trybie kontroli i o karach wchodzą w życie 28 października 2026. ### Zakres tej strony Jesteśmy zespołem inżynierskim, nie kancelarią. Opisujemy tu, jak wykonać obowiązek w produkcie i jak sprawdzić, że działa, a nie jak brzmi jego wykładnia dla waszego przypadku. Granice zakresu, w szczególności przy tekstach publikowanych i przy wyjątkach z art. 50, rozstrzyga radca prawny: wasz albo nasz partner prawny. Daty i numery aktów podajemy razem ze źródłami. ### Powiązane - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zgodnosc-z-ai-act - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/ewaluacja-jakosci-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna ### Źródła - Ministerstwo Cyfryzacji: AI Act, co się zmieniło 2 sierpnia 2026 roku: https://www.gov.pl/web/cyfryzacja/ai-act--co-sie-zmienilo-2-sierpnia-2026-roku - Rozporządzenie (UE) 2024/1689 (AI Act), tekst w EUR-Lex: https://eur-lex.europa.eu/eli/reg/2024/1689/oj - Pinsent Masons: prawo przesuwające unijne przepisy o AI wysokiego ryzyka sfinalizowane: https://www.pinsentmasons.com/out-law/news/law-delaying-eu-high-risk-ai-rules-finalised - Ustawa z 3 lipca 2026 o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003): https://eli.gov.pl/api/acts/DU/2026/1003/text/O/D20261003.pdf - Rozporządzenie (UE) 2026/1744 (omnibus cyfrowy), tekst w EUR-Lex: https://eur-lex.europa.eu/eli/reg/2026/1744/oj --- ## Analiza kosztów LLM: trafienia w cache promptów i twarde limity wydatku **URL:** https://23minds.com/pl/przewodniki/koszty-llm-i-cache-promptow > Analiza przypisuje koszty LLM do funkcji i sesji, wskazuje wywołania bez odczytu z cache i sprawdza przyczyny dodatkowych kosztów, a limity blokują kolejne wywołania po wyczerpaniu budżetu. Cache promptów to mechanizm dostawcy, który zapisuje niezmienny początek żądania (prefiks) i przy kolejnych żądaniach rozlicza go taniej; znacznik cache wskazuje, gdzie prefiks się kończy. Analizę czyta się wywołanie po wywołaniu: trafienie albo chybienie, koszt, przyczyna chybienia. ### Podsumowanie 23Minds prowadzi analizę trafień w cache promptów i instaluje twarde limity wydatku dla zespołów inżynierskich, których rachunek za LLM rośnie szybciej niż ruch. Praca przypisuje każde wywołanie do funkcji i sesji, odczytuje pola cache zwracane przez dostawcę w każdej odpowiedzi i wskazuje potwierdzone przyczyny chybień, oddzielając przypadki do dalszych testów: przepisany prefiks, proxy gubiące znacznik cache, seria równoległych żądań, wygasły czas życia wpisu. Klient zatrzymuje raport z tabelą dla każdego wywołania, układ prefiksu, który cały zespół może sprawdzić skrótem, oraz rejestr limitów mówiący, co dzieje się z każdą funkcją po wyczerpaniu jej budżetu. Oszczędność mierzy się na raporcie użycia dostawcy przed poprawkami i po nich, przy porównywalnym obciążeniu. ### Dla kogo to jest - CTO i wiceprezesi ds. inżynierii, którzy dostali rachunek, którego nie umieli wyjaśnić z panelu użycia - Zespoły platformowe prowadzące bramę albo proxy do LLM (LiteLLM, własny router, Bedrock za warstwą zgodną z OpenAI) - Zespoły wdrażające pętle agentów, w których każda tura wysyła ponownie całą rozmowę - Partnerzy z działu finansów, którzy potrzebują kosztu LLM w podziale na funkcje produktu i na klientów, a nie na klucze API ### Rachunek czytany jak faktura Raport użycia dostawcy odpowiada na jedno pytanie: ile tokenów każdego rodzaju przeszło przez każdy klucz API, na model, na dzień. Usage and Cost API Anthropic grupuje po kluczu API, workspace, modelu i poziomie usługi oraz dzieli wejście na tokeny bez cache, zapis do cache i odczyt z cache; Usage API OpenAI i Cloud Billing Google dają podobny podział, z własnymi polami i zasadami rozliczeń. Żaden z nich nie wie, czym jest funkcja ani sesja, bo ta informacja żyje w waszym kodzie. Faktura potrzebuje trzech złączeń, których panel nie ma. Po pierwsze, każde żądanie niesie nazwę funkcji, identyfikator sesji i klienta (tenant) jako metadane, logowane w bramie obok identyfikatora żądania od dostawcy. Po drugie, blok usage z każdej odpowiedzi jest zapisywany dla każdego wywołania, a nie sumowany na dzień: Anthropic zwraca cache_creation_input_tokens i cache_read_input_tokens, OpenAI zwraca input_tokens_details.cached_tokens i cache_write_tokens, Converse API w Bedrocku zwraca cacheReadInputTokens i cacheWriteInputTokens. Po trzecie, cennik z mnożnikami za zapis i odczyt jest stosowany do każdego wywołania, więc każde żądanie ma własny koszt. Z tymi złączeniami pytanie zmienia się z: dlaczego rachunek jest wysoki, na: która funkcja, w których sesjach, zapłaciła pełną cenę wejścia za prefiks, który powinien był być w cache. Na takie pytanie istnieje odpowiedź w postaci rankingu. ### Jak trzej dostawcy rozliczają pamięć podręczną promptów Mechanika różni się na tyle, że ogólna zasada od jednego dostawcy daje chybienia u drugiego. Tabela poniżej pochodzi z dokumentacji dostawców sprawdzonej we wrześniu 2026; odnośniki do źródeł, po jednym na dostawcę, są na końcu strony. | Dostawca | Co jest buforowane | Czas życia | Cena zapisu i odczytu | Gdzie widać trafienie | | --- | --- | --- | --- | --- | | Anthropic (Claude API) | Prefiks kończący się na punkcie cache_control, w kolejności: narzędzia, system, wiadomości; minimum od 512 do 4 096 tokenów zależnie od modelu | 5 minut domyślnie, 1 godzina opcjonalnie | Zapis 1,25x ceny wejścia (5 min) albo 2x (1 godzina); odczyt 0,1x, w niektórych modelach 0,025x | cache_creation_input_tokens, cache_read_input_tokens | | OpenAI | Automatyczne dopasowanie dokładnego prefiksu od 1 024 widocznych tokenów; definicje narzędzi, schematy i ustawienia rozumowania są częścią prefiksu | 30 minut od ostatniego zapisu albo użycia w GPT-5.6 i nowszych; 5-10 minut bezczynności, do godziny, we wcześniejszych modelach | Odczyt 0,1x ceny wejścia bez cache w GPT-5.6 i nowszych; wcześniej stawki zależne od modelu | input_tokens_details.cached_tokens, cache_write_tokens | | Google Gemini | Cache niejawny włączony domyślnie w Gemini 2.5 i nowszych, od 2 048 albo 4 096 tokenów; cache jawny tworzony przez wywołującego | Domyślny czas życia cache jawnego 1 godzina, konfigurowalny | Tokeny z cache po obniżonej stawce plus cena przechowywania za milion tokenów na godzinę dla cache jawnego | tokeny z cache w metadanych użycia | | Amazon Bedrock (Claude) | Blok cachePoint w Converse albo cache_control w InvokeModel, ta sama kolejność sekcji; minimum liczy wszystkie sekcje razem | 5 minut, 1 godzina w obsługiwanych modelach; odnawia się przy każdym trafieniu | Odczyt po stawce cache danego modelu; zapis może być rozliczany powyżej ceny wejścia | cacheReadInputTokens, cacheWriteInputTokens; dokumentacja mówi, że obsługa nie gwarantuje trafienia | ### Co po cichu psuje prefiks Analiza sprawdza trzy rzeczy: zmiany prefiksu między żądaniami, wygaśnięcie wpisu i moment wysłania żądań; nie zawsze pozwala ustalić przyczynę, bo dostawcy nie gwarantują trafienia. Katalog poniżej to przyczyny, które diff w analizie potrafi potwierdzić. - Warstwa oszczędzająca tokeny, która przepisuje historię. Kompresja albo przycinanie starszych wiadomości zmienia bajty przed punktem podziału w każdej turze, więc każda tura zapisuje nowy wpis po 1,25x zamiast czytać po 0,1x. Praktycy na forach programistów opisali dokładnie to: wtyczka sprzedawana jako oszczędzająca tokeny podniosła rachunek w Anthropic. Mniej tokenów po pełnej cenie kosztuje więcej niż więcej tokenów po jednej dziesiątej. - Definicje narzędzi, które się zmieniają albo zmieniają kolejność. Narzędzia leżą na początku prefiksu, więc dodane narzędzie, zmieniony opis albo lista renderowana z nieuporządkowanego zbioru unieważnia wszystko za sobą. - Dynamiczna treść na górze promptu systemowego: znacznik czasu, nazwa użytkownika, identyfikator żądania. Jeden bajt przed punktem podziału i to już inny prefiks. - Proxy, które nie przenosi znacznika. Warstwa zgodna z OpenAI przed Bedrockiem musi przetłumaczyć cache_control na blok cachePoint; jeśli go gubi, każda warstwa nadal deklaruje obsługę cache, a nic nie jest buforowane. Jeden publicznie opisany przypadek: Droid przez LiteLLM do Bedrocka, koniec na 37 901,73 USD i około 6,47 mld tokenów wejścia bez cache. - Serie równoległych żądań. Anthropic dokumentuje, że wpis staje się dostępny dopiero po rozpoczęciu pierwszej odpowiedzi, więc żądania wysłane naraz mogą zwiększyć liczbę płatnych zapisów tego samego prefiksu; analiza sprawdza to w danych użycia. - Przełączniki parametrów. Parametry extended thinking i effort, tool_choice, schematy wyjścia i ustawienia rozumowania są częścią tożsamości prefiksu w Anthropic i OpenAI; flaga funkcji, która przełącza jeden z nich, przełącza cache. - Wygasły czas życia. Zadanie wsadowe, które wysyła jedno żądanie na dokument co dwadzieścia minut, nigdy nie użyje ponownie wpisu pięciominutowego; Anthropic oferuje na taki kształt opcję godzinną, a domyślne okno OpenAI w GPT-5.6 to 30 minut. - Arytmetyka pętli agentów. Przy przesyłaniu pełnej historii i podobnej długości kolejnych tur łączna liczba tokenów wejścia w sesji rośnie w przybliżeniu kwadratowo z liczbą tur. Z trafieniami większość tych tokenów jest rozliczana po 0,1x; bez nich całość po pełnej cenie. ### Gdzie kończy się alert, a zaczyna twardy stop Alert to e-mail z opóźnieniem liczonym w godzinach; rozpędzona pętla liczy się w żądaniach na sekundę. Kontrole u dostawców, które naprawdę zatrzymują ruch, różnią się między sobą, a te różnice decydują o projekcie. - Limity na funkcję i na klienta nie istnieją u żadnego dostawcy. Żyją w waszej bramie: licznik na funkcję i na klienta, budżet i kontrolowany błąd po jego osiągnięciu. - Limit to decyzja produktowa. Zanim zostanie włączony, każda funkcja dostaje spisaną odpowiedź na pytanie, co widzi użytkownik, gdy to się zatrzyma. Po wyczerpaniu budżetu funkcji w bramie: tryb ograniczony, kolejka albo mniejszy model. Po blokadzie u dostawcy: czytelny komunikat, bo wtedy tańszy model też nie odpowie. - Limit, który nigdy nie zadziałał, jest domysłem. Próba to syntetyczna pętla na projekcie testowym, która dochodzi do limitu, z zapisem, ile trwało egzekwowanie i kto został wezwany. | Dostawca | Co zatrzymuje ruch | Co tylko powiadamia | Zakres limitu | | --- | --- | --- | --- | | Anthropic | Miesięczny limit wydatku na workspace oraz limity zapytań i tokenów na minutę na workspace | Alerty wydatku przy progach | Workspace; nie na domyślnym workspace, nie na klucz API | | OpenAI | Twardy limit wydatku na organizację albo projekt: żądania zwracają 429 z organization_spend_limit_exceeded albo project_spend_limit_exceeded; egzekwowanie nie jest natychmiastowe, więc koszt może przekroczyć próg do czasu blokady | Alerty wydatku, ruch trwa dalej | Organizacja i projekt | | Google Cloud (Gemini przez Cloud Billing) | Budżet z limitem wydatku (podgląd) dla kwalifikujących się usług albo powiadomienie budżetowe przez Pub/Sub podpięte pod kod, który wyłącza rozliczanie projektu | Budżety tylko alertowe, które według dokumentacji nie ograniczają użycia ani wydatku | Konto rozliczeniowe i projekt | ### Jak wygląda raport z analizy i co zespół z nim robi Rdzeniem raportu jest jedna tabela z jednym wierszem na wywołanie. Wszystko inne w raporcie jest agregatem tej tabeli, więc każdą liczbę ze streszczenia da się prześledzić do żądań, które ją wytworzyły. - Przyczyny chybień szeregujcie według pieniędzy, które za nimi stoją, a nie według częstości. Ranking pokazuje, ile kosztu niesie każda przyczyna. - Najdroższe przyczyny naprawiajcie u źródła: zmieńcie kolejność promptu, przypnijcie listę narzędzi, przenieście dynamiczną treść pod punkt podziału, wysyłajcie pierwsze żądanie na prefiks pojedynczo, naprawcie tłumaczenie w proxy. - Po zmianie uruchomcie tę samą tabelę na raporcie użycia dostawcy jeszcze raz przy porównywalnym obciążeniu i zapiszcie warunki pomiaru: ruch, modele, ceny, długość odpowiedzi. Stan przed i po pochodzi wtedy z tego samego źródła. - Limit awaryjny u dostawcy ustawcie przed analizą, a budżety funkcji dopasujcie po pomiarze, żeby były ustawione wobec prawdziwego zużycia, a nie wobec błędu. | Kolumna | Co zawiera | Skąd pochodzi | | --- | --- | --- | | Wywołanie | Identyfikator żądania od dostawcy, znacznik czasu, model | Nagłówki odpowiedzi i blok usage | | Funkcja i sesja | Nazwa funkcji, identyfikator sesji, klient | Metadane, które wasza brama dołącza do żądania | | Prefiks | Skrót bajtów do ostatniego punktu podziału i pozycja, na której po raz pierwszy różni się od poprzedniego wywołania w sesji | Log bramy, porównany offline | | Trafienie albo chybienie | Tokeny odczytane, zapisane i bez cache | Blok usage, według nazw pól dostawcy | | Koszt | Cena za klasę tokenów w dniu wywołania | Cennik dostawcy, wasza faktura | | Przyczyna chybienia | Jedna pozycja z katalogu powyżej albo: niewyjaśnione | Diff, odstęp między wywołaniami, ślad z proxy | ### Gdzie to się psuje i co z tym robimy **Warstwa oszczędzająca tokeny przepisuje prefiks w każdej turze** Wtyczka kompresująca albo przycinająca historię siedzi między aplikacją a dostawcą i edytuje starsze wiadomości, żeby wysłać mniej tokenów. Edycja zmienia bajty przed punktem podziału cache, więc każda tura tworzy nowy wpis po cenie zapisu i nic nie czyta. Panel pokazuje mniej tokenów wejścia i wyższy rachunek, a zespół czyta to jako model, który zdrożał. Co z tym robimy: Logujemy kolejne żądania z sesji w bramie i porównujemy je bajt po bajcie, żeby znaleźć pierwszą rozbieżność. Tam, gdzie leży ona wewnątrz rzekomo statycznego prefiksu, przenosimy dynamiczną edycję pod punkt podziału albo usuwamy warstwę. Potem porównujemy cache_read_input_tokens z całym wejściem na raporcie użycia dostawcy dla tej samej funkcji przed zmianą i po niej. Co zostaje u was: raport diffu dla każdej sesji z pozycją rozbieżności dla każdego wywołania oraz udział odczytów z cache przed zmianą i po niej **Proxy w łańcuchu gubi znacznik cache** Aplikacja oznacza punkt podziału, proxy zgodne z OpenAI przekazuje żądanie do Bedrocka, a znacznik nigdy nie staje się blokiem cachePoint. Każda warstwa w łańcuchu dokumentuje obsługę pamięci podręcznej promptów i właśnie to zespół sprawdził. Nic w łańcuchu nie raportuje, że znacznik zginął; jedynym dowodem jest to, że tokeny odczytane z cache po stronie dostawcy zostają na zerze. Co z tym robimy: Odtwarzamy jedno stałe żądanie przez każdy przeskok w łańcuchu i odczytujemy pola cache zwracane na każdym z nich, więc warstwa, która gubi znacznik, jest nazwana, a nie podejrzewana. Naprawiamy tłumaczenie albo konfigurację na tym przeskoku i powtarzamy odtworzenie, aż dostawca zaraportuje odczyty. Co zostaje u was: tabela śladu przeskok po przeskoku dla stałego żądania, z polami cache zwracanymi na każdej warstwie **Dynamiczna treść leży nad punktem podziału** Prompt systemowy zaczyna się od bieżącej daty, nazwy użytkownika albo identyfikatora żądania, albo lista narzędzi jest renderowana ze zbioru bez stałej kolejności. Prefiks różni się w każdym wywołaniu o kilka bajtów, a dostawca słusznie traktuje go jako nowy. To częsta przyczyna i tania w naprawie, a bez diffu pozostaje niewidoczna. Co z tym robimy: Spisujemy układ promptu jako uporządkowaną listę bloków ze stroną statyczną i dynamiczną, przypinamy kolejność narzędzi i przenosimy każdą wartość zależną od żądania za ostatni punkt podziału. Układ dostaje skrót, który brama sprawdza przy każdym żądaniu, więc test wykrywa zmianę statycznego prefiksu przed wdrożeniem. Co zostaje u was: specyfikacja układu promptu ze skrótem prefiksu i kontrola w bramie, która nie przechodzi przy zmianie części statycznej **Alert się odzywa i nic się nie zatrzymuje** Alert budżetowy jest skonfigurowany u dostawcy, a pętla z błędem w warunku wyjścia rusza w nocy. E-mail przychodzi przy progu, dyżurny czyta go rano, a wydatek pomiędzy jest incydentem. Alert dostawcy zrobił to, do czego był zaprojektowany; projekt zakładał człowieka w pętli przy prędkości żądań. Co z tym robimy: Ustawiamy u dostawcy kontrolę, która naprawdę zatrzymuje ruch: limit wydatku na workspace w Anthropic, twardy limit projektu w OpenAI, limit wydatku albo funkcję wyłączającą rozliczanie w Google Cloud. Nad tym dodajemy w waszej bramie budżety na funkcję i na klienta z kontrolowanym błędem i przeprowadzamy próbę, która dochodzi do każdego limitu na projekcie testowym, żeby zapisać opóźnienie egzekwowania. Co zostaje u was: rejestr limitów dla każdego dostawcy i każdej funkcji, z zachowaniem widocznym dla użytkownika po osiągnięciu każdego limitu i wynikami próby **Równoległe rozgałęzienie i ponowienia zapisują ten sam prefiks wiele razy** Funkcja wysyła naraz dziesięć żądań z tym samym prefiksem albo polityka ponowień wysyła pełny prompt przy każdym 429. Anthropic dokumentuje, że wpis w cache staje się dostępny dopiero po rozpoczęciu pierwszej odpowiedzi, więc seria może zapisać wpis raz na żądanie i nie odczytać go ani razu; dane użycia to potwierdzają albo nie. Wskaźnik trafień wygląda akceptowalnie w średniej i fatalnie dokładnie w tych funkcjach, które się rozgałęziają. Co z tym robimy: Wysyłamy pierwsze żądanie na prefiks pojedynczo i zwalniamy resztę, gdy wpis już istnieje, ograniczamy ponowienia i dodajemy losowy odstęp, a stosunek zapisów do odczytów mierzymy dla każdej funkcji, nie dla klucza. Funkcje, które się rozgałęziają, dostają własny wiersz w raporcie, żeby średnia nie mogła ich ukryć. Co zostaje u was: stosunek zapisów do odczytów dla każdej funkcji, przed zmianą i po niej, z raportu użycia dostawcy ### Co dostajecie - Raport z analizy z jednym wierszem na wywołanie: funkcja, sesja, skrót prefiksu, trafienie albo chybienie, tokeny według klas, koszt, przyczyna chybienia - Przypisanie kosztu do funkcji, sesji i klienta, uzgodnione z raportem kosztów dostawcy za ten sam okres - Specyfikacja układu promptu ze skrótem prefiksu i kontrola w bramie, która nie przechodzi przy zmianie części statycznej - Rejestr limitów: dla każdego dostawcy i każdej funkcji, co zatrzymuje, co powiadamia, co widzi użytkownik i kto jest wzywany - Zapis próby: każdy limit osiągnięty raz na projekcie testowym, ze zmierzonym opóźnieniem egzekwowania - Pomiar przed i po na raporcie użycia dostawcy, przy porównywalnym obciążeniu i z zapisanymi warunkami, z użytym zapytaniem, żeby dział finansów mógł go powtórzyć ### Jak pracujemy 1. **1. Zbieranie** (Tydzień 1-2): Ustawiamy limit awaryjny u dostawcy, dołączamy metadane funkcji, sesji i klienta w waszej bramie, zapisujemy blok usage z każdej odpowiedzi i pobieramy raporty użycia i kosztów dostawcy za to samo okno. Okres zbierania zależy od ruchu i musi objąć typowe zadania oraz okresy zwiększonego obciążenia. 2. **2. Analiza** (Tydzień 2-3): Budujemy tabelę dla każdego wywołania, porównujemy kolejne żądania w sesji, odtwarzamy stałe żądanie przez każdy przeskok łańcucha proxy i przypisujemy potwierdzoną przyczynę każdemu chybieniu, które da się wyjaśnić. Przyczyny szeregujemy według pieniędzy, które za nimi stoją. 3. **3. Poprawki i limity** (Tydzień 3-5): Najdroższe przyczyny naprawiamy u źródła razem z waszym zespołem, spisujemy układ promptu z jego skrótem, a potem dopasowujemy limit u dostawcy i ustawiamy budżety na funkcję ze zdefiniowanym zachowaniem dla każdego. Każdy limit osiągamy raz na projekcie testowym. 4. **4. Ponowny pomiar i przekazanie** (Tydzień 5-6): Uruchamiamy tę samą tabelę na raporcie użycia dostawcy po zmianie przy porównywalnym obciążeniu i przekazujemy raport, specyfikację układu, kontrolę w bramie i rejestr limitów. Kontrola zostaje w waszym potoku, żeby następna edycja promptu nie mogła po cichu otworzyć chybień na nowo. ### FAQ **Q: Panel dostawcy już pokazuje tokeny z cache. Po co tabela dla każdego wywołania?** Panel sumuje po kluczu API i po dniu, więc funkcja z zerem trafień znika wewnątrz klucza ze zdrową średnią. Tabela dla każdego wywołania trzyma funkcję, sesję i prefiks obok pól użycia i to właśnie pozwala przypisać chybieniu przyczynę. Usage and Cost API Anthropic jest źródłem do uzgodnienia kwot; nie jest diagnozą. **Q: Czy wskaźnik trafień w cache, powiedzmy 80%, oznacza, że system jest w porządku?** Najpierw trzeba ustalić, jak wskaźnik jest liczony: po żądaniach czy po tokenach i z jakim mianownikiem. Jeśli oznacza, że 80% kwalifikujących się tokenów zostało odczytanych z cache we wszystkim, co wysłał ten klucz, to Nie mówi nic o tym, które funkcje dostały pozostałe 20% ani ile to kosztowało. Raportujemy stosunek zapisów do odczytów dla każdej funkcji i pieniądze dla każdej przyczyny chybienia, bo jedna pętla agenta z dynamiczną treścią nad punktem podziału może przeważyć wszystkie inne funkcje razem. **Q: Czy kompresja promptu albo przycinanie historii kiedykolwiek się opłaca?** Tak, gdy przycinana treść leży za ostatnim punktem podziału albo gdy prefiks i tak jest poniżej minimalnego rozmiaru buforowanego u dostawcy. Test jest arytmetyczny, dla każdej funkcji: pełny koszt obu wariantów dla tych samych zadań, z zapisami, odczytami, przechowywaniem i częstością ponownego użycia prefiksu. Ten rachunek robimy na waszym ruchu, zanim jakakolwiek warstwa zostanie włączona albo wyłączona. **Q: Który limit wydatku ustawić najpierw?** Ten, który zatrzymuje ruch u dostawcy: limit wydatku na workspace w Anthropic, twardy limit projektu w OpenAI, limit wydatku albo automatyzację wyłączającą rozliczanie w Google Cloud. Alerty zostają jako wczesne ostrzeżenie, ale niczego nie ograniczają. Budżety na funkcję i na klienta idą dalej, w waszej bramie, bo żaden dostawca ich nie oferuje. **Q: Co dzieje się z produktem po osiągnięciu twardego limitu?** To, co zdecydowano wcześniej i zapisano w rejestrze limitów: tryb ograniczony, kolejka, mniejszy model albo czytelny błąd. OpenAI zwraca 429 z nazwanym kodem błędu; Anthropic zatrzymuje workspace na miesięcznym limicie wydatku. Jeśli nikt nie zdecydował, produkt decyduje za was, zwykle pustym ekranem. Dlatego każdy limit jest osiągany raz na projekcie testowym, zanim wejdzie na produkcję. **Q: Czy liczby z tej strony dotyczą naszej umowy?** Mnożniki i czasy życia pochodzą z publicznej dokumentacji dostawców według stanu na wrzesień 2026 i są podlinkowane poniżej. Umowy enterprise, cenniki Bedrocka i Vertexa różnią się, a minimalne rozmiary buforowane zmieniają się z każdym wydaniem modelu. Raport stosuje cennik obowiązujący w dniu każdego wywołania, z waszej faktury, a nie z tej strony. **Q: Korzystamy z Bedrocka za proxy zgodnym z OpenAI. Czy cache tam w ogóle działa?** Działa, gdy proxy tłumaczy znacznik cache na blok cachePoint Bedrocka albo gdy niejawny cache modelu podchwyci prefiks. Żadne z tych dwojga nie jest gwarantowane, a dokumentacja AWS mówi to wprost: obsługa cache nie gwarantuje trafienia. Jedynym dowodem jest cacheReadInputTokens w odpowiedzi i właśnie to odczytuje odtworzenie przeskok po przeskoku na każdej warstwie. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability ### Źródła - Anthropic, Prompt caching: breakpointy, kolejność, czas życia, mnożniki cen, pola usage, uwaga o równoległości: https://platform.claude.com/docs/en/build-with-claude/prompt-caching - Anthropic, Workspaces: miesięczne limity wydatku i limity zapytań per workspace: https://platform.claude.com/docs/en/manage-claude/workspaces - Anthropic, Usage and Cost API: grupowanie po kluczu API, workspace i modelu; klasy tokenów z cache i bez: https://platform.claude.com/docs/en/manage-claude/usage-cost-api - OpenAI, Prompt caching: dopasowanie prefiksu, minimalna długość, czas przechowywania, rabat za tokeny z cache, pola usage: https://developers.openai.com/api/docs/guides/prompt-caching - OpenAI, Spend limits: twarde limity per organizacja i projekt, kody błędów 429, alerty: https://developers.openai.com/api/docs/guides/spend-limits - Google, Gemini API context caching: domyślny cache niejawny i minimalne liczby tokenów: https://ai.google.dev/gemini-api/docs/caching - Google, Gemini API cache jawny: domyślny TTL 1 godzina i składniki rozliczenia: https://ai.google.dev/gemini-api/docs/generate-content/caching - Google, cennik Gemini API: context caching i opłata za przechowywanie na godzinę: https://ai.google.dev/gemini-api/docs/pricing - Google Cloud, budżety Cloud Billing: budżety alertowe nie ograniczają wydatku: https://docs.cloud.google.com/billing/docs/how-to/budgets - AWS, Amazon Bedrock prompt caching: cachePoint, kolejność sekcji, TTL, brak gwarancji trafienia: https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-caching.html - Przypadek opisany przez autora na Hacker News: rachunek 37 901,73 USD na Bedrocku po chybieniach cache w łańcuchu proxy: https://news.ycombinator.com/item?id=47933355 --- ## Pomiar rzeczywistego efektu AI w zespole inżynierskim: protokół, który przyjmą zarząd i zespół **URL:** https://23minds.com/pl/przewodniki/pomiar-efektu-ai-w-zespole-inzynierskim > Pomiar efektu asystentów AI pokazuje, jak po wdrożeniu zmieniły się tempo pracy zespołu i liczba poprawek. Protokół bierze punkt odniesienia sprzed wdrożenia, stawia miarę stabilności obok każdej miary tempa i działa na danych, które zespół już ma w gicie, w CI i w systemie zgłoszeń. Jest przeznaczony dla wdrożenia, które już trwa albo się zakończyło. ### Podsumowanie 23Minds projektuje i prowadzi pomiar efektu asystentów AI dla zespołów inżynierskich, których zarząd pyta, co zmieniły narzędzia AI, a zespół chce liczb, które przyjmie. Protokół bierze punkt odniesienia z historii gita i CI sprzed pierwszej licencji, zestawia każdą miarę przepustowości z miarą stabilności z tego samego okna, przydziela grupy porównawcze zespołami zamiast ochotnikami i raportuje wyłącznie na poziomie zespołu, nigdy dla poszczególnych osób. Opublikowane wyniki wskazują w przeciwne strony, od 19% wolniej w badaniu z randomizacją wśród doświadczonych programistów open source do 26% więcej ukończonych zadań u 4 867 programistów w trzech firmach, dlatego odpowiedź dla danego zespołu pochodzi z jego własnych danych. Klient zatrzymuje protokół, arkusz punktu odniesienia, panel miar w parach z zapytaniami i raport po zamknięciu okna pomiaru trwającego 8-12 tygodni, który mówi, co zmierzono, czego nie i dlaczego. ### Dla kogo to jest - CTO i wiceprezesi ds. inżynierii, którzy muszą pokazać zarządowi, czy budżet na narzędzia AI cokolwiek zmienił, liczbą, której umieją bronić - Szefowie inżynierii, których zespół już się spiera, czy zrobiło się lepiej, czy gorzej, bez danych, które zaakceptowałaby którakolwiek strona - Menedżerowie inżynierii, którym polecono wprowadzić miary produktywności i którzy wiedzą, co dzieje się z zespołem, gdy miara jest liczona dla poszczególnych osób - Zespoły platformowe i zespoły od środowiska pracy programistów, które są właścicielami CI, repozytorium i systemu zgłoszeń i będą prowadzić pomiar po przekazaniu ### Dlaczego szybsze zamykanie zgłoszeń nie jest dowodem Krótszy czas zamykania zgłoszeń nie pokazuje kosztu późniejszych poprawek ani pracy recenzentów. Nie mówi, czy zmiana została poprawiona po scaleniu, czy recenzent spędził czas, który zaoszczędził autor, ani czy następna zmiana w tym samym pliku trwała dłużej. Raport DORA 2025, oparty na odpowiedziach ankietowych prawie 5 000 specjalistów z branży, wykazał dodatnią zależność między adopcją AI a przepustowością dostarczania oprogramowania i, w tych samych danych, ujemną zależność ze stabilnością dostarczania. Według samego raportu przyspieszenie odsłania słabości dalej w procesie, gdy brakuje systemów kontrolnych, testów automatycznych, dobrej praktyki kontroli wersji i szybkiej informacji zwrotnej, które wchłonęłyby dodatkowy wolumen zmian. Liczba przepustowości sama w sobie to pół wyniku. Raport DORA o zwrocie z inwestycji z kwietnia 2026 wycenia drugą połowę na poglądowym modelu: w jego przykładowym kalkulatorze dla organizacji inżynierskiej z 500 osobami wskaźnik nieudanych zmian, który po adopcji rośnie z 5% do 6%, pokazuje się jako ujemny wpływ przestojów rzędu 344 000 USD. Ta liczba to przykład obliczeniowy z założeniami tego modelu (500 osób, przyjęty koszt przestoju), nie pomiar żadnej firmy. Jest tu przytoczona z jednego powodu: w tym modelu ruch o jeden punkt w mierze stabilności wystarczył, żeby skasować widoczny zysk w tempie. Spór wewnątrz zespołów ma ten sam kształt. W dyskusjach praktyków z 2026 roku na ten temat chodzi o to, czy kod za zamkniętym zgłoszeniem jest gorszy i czy presja na utrzymanie tempa powstrzymuje kogokolwiek przed sprawdzeniem. Bez protokołu obie strony mają rację. Raport pokazuje zmianę wyników oraz granice przypisania jej asystentom AI. ### Co pokazują badania nad efektami AI Opublikowane badania mierzą różne rzeczy różnymi metodami: dwa to eksperymenty z randomizacją, jedno to ankieta przekrojowa. Ich wyniki dają się porównać dopiero wtedy, gdy widać sposób uzyskania każdego z nich. Tabela wymienia badania, o których zarząd najprawdopodobniej słyszał. Żadne z nich nie zmierzyło waszego zespołu. | Badanie | Populacja i projekt | Mierzony wynik | Rezultat | Co to znaczy dla pomiaru w zespole | | --- | --- | --- | --- | --- | | METR, badanie z randomizacją, luty-czerwiec 2025 (Becker i in., arXiv 2507.09089) | 16 doświadczonych programistów open source, 246 prawdziwych zadań na ich własnych repozytoriach, losowo z AI dozwoloną albo zabronioną, Cursor Pro z Claude 3.5 i 3.7 Sonnet | Czas ukończenia zadania | 19% dłużej z dozwoloną AI; programiści przewidywali 24% szybciej i po badaniu nadal szacowali 20% szybciej | Deklarowane tempo nie jest pomiarem. W tej populacji doświadczeni programiści na dobrze znanym kodzie nie zyskali na czasie. | | METR, dane z końca 2025 i korekta metodyki (24 lutego 2026) | 57 programistów, ponad 800 zadań w 143 repozytoriach; stawka obniżona ze 150 do 50 USD za godzinę | Czas ukończenia zadania, ten sam projekt | Oszacowania punktowe przesunęły się w stronę przyspieszenia, z szerokimi przedziałami; METR uznał sygnał za niewiarygodny, bo programiści odmawiali pracy bez AI, a 30-50% wstrzymało zadania, które bez AI zapowiadały się wolno | Samoselekcja psuje projekt. Kto się zgłasza i które zadania oddaje, decyduje o wyniku, zanim cokolwiek zostanie zmierzone. | | Cui i in., trzy eksperymenty terenowe (Management Science, 2026) | 4 867 programistów w Microsoft, Accenture i firmie z listy Fortune 100, losowy podzbiór dostał asystenta uzupełniania kodu w zwykłej pracy | Ukończone zadania | 26,08% więcej ukończonych zadań (błąd standardowy 10,3%); mniej doświadczeni programiści częściej przyjmowali narzędzie i więcej zyskiwali | Inna populacja, inny wynik, przeciwny znak. W tym badaniu więcej zyskali mniej doświadczeni, a liczba ukończonych zadań nic nie mówi o poprawkach. | | DORA, State of AI-assisted Software Development 2025 | Ankieta prawie 5 000 specjalistów plus ponad 100 godzin wywiadów; przekrojowa, bez randomizacji | Deklarowana przepustowość i stabilność | Przepustowość rośnie z adopcją, stabilność z adopcją spada | Te dwie miary trzeba czytać jako parę. Wdrożenie, które raportuje tylko jedną z nich, raportuje tę połowę, która mu pasuje. | ### Projekt pomiaru Protokół, który przyjmą zarząd i zespół, ma pięć części. Każda istnieje dlatego, że bez niej konkretne badanie zawiodło. Wszystko poniżej liczy się z historii gita, logów CI i systemu zgłoszeń; zakres zależy od tego, co te systemy przechowują, a sprawdzamy to w pierwszym tygodniu. Nie jest potrzebna żadna platforma komercyjna, a panel wskaźnika akceptacji od dostawcy nie jest danymi wejściowymi. - Punkt odniesienia sprzed wdrożenia. Dwanaście tygodni historii przed pierwszą licencją, dla każdej miary, która będzie raportowana później, odtworzonych z gita i CI, jeśli nikt nie zebrał ich na bieżąco. Pomiar bez stanu sprzed wdrożenia nie ma z czym się porównać poza wrażeniem. - Miary w parach. Każda miara tempa jest raportowana obok miary stabilności z tego samego okna i tych samych repozytoriów: czas realizacji zmiany obok czasu do pierwszej poprawki po scaleniu (liczonego w oknie 30 dni, razem z udziałem zmian bez poprawki, bo sam dłuższy czas może znaczyć zarówno stabilniejszy kod, jak i późniejsze wykrywanie błędów); scalone pull requesty na tydzień obok udziału scaleń, po których w ciągu 30 dni nastąpił revert albo hotfix; częstość wdrożeń obok wskaźnika nieudanych zmian. Para może poruszyć się w przeciwne strony i to właśnie jest ustalenie. - Okno dość długie, żeby objąć dołek. Osiem do dwunastu tygodni po wdrożeniu, bo pierwsze tygodnie każdej zmiany narzędzi niosą koszt nauki, który migawka z czterech tygodni odczyta jako porażkę albo, wzięta późno, jako czysty zysk. - Grupa porównawcza zespołami, nie ochotnikami. Tam, gdzie organizacja wdraża falami, zespoły, które jeszcze czekają, są grupą porównawczą, po sprawdzeniu podobieństwa zespołów, zadań i wcześniejszych trendów oraz z zapisanym ograniczeniem nielosowego przydziału. Tam, gdzie nie może, porównaniem jest własny punkt odniesienia tego samego zespołu, z ograniczeniem zapisanym w raporcie. Ochotnicy nigdy nie są porównaniem, bo dane METR pokazują, co się dzieje, gdy entuzjaści się zgłaszają, a sceptycy wycofują. - Krótka lista tego, czego się nie liczy. Linie kodu, liczba commitów, liczba otwartych pull requestów i wskaźnik akceptacji podpowiedzi asystenta są wyłączone jako samodzielne wyniki, bo narzędzie zawyża każdą z tych liczb bez żadnej zmiany w tym, co trafia do użytkowników. Scalone pull requesty na tydzień wchodzą tylko w parze z udziałem revertów i hotfixów; reszta zostaje w danych jako mianowniki. ### Miary dla poszczególnych osób i dlaczego psują pomiar Najszybszy sposób na utratę pomiaru to publikacja wyników dla poszczególnych osób. Ramy SPACE (Forsgren i in., ACM Queue 2021) formułują zasadę: produktywności programisty nie da się uchwycić jedną miarą ani poziomem aktywności pojedynczej osoby. Ranking inżynierów według użycia asystenta albo wskaźnika akceptacji szybko zamienia miarę w cel. Ludzie uruchamiają narzędzie, żeby było widać, że go używają, przyjmują podpowiedzi, które inaczej by przepisali, a liczba rośnie, podczas gdy to, co miała reprezentować, przestaje się ruszać. Pracodawcy zaczęli już uwzględniać indywidualne użycie AI w ocenach okresowych, jak podał The Register w listopadzie 2025, a wątki praktyków po takich ogłoszeniach szczegółowo opisują opór, który to wywołuje. Dane o zaufaniu tłumaczą ten opór. Ankieta Stack Overflow 2025 zebrała 49 009 odpowiedzi. Na pytanie o frustracje odpowiedziało 31 476 osób i 66% z nich wskazało wynik AI, który jest prawie dobry, ale nie do końca; to najczęstsza odpowiedź. 45,2% stwierdziło, że debugowanie kodu napisanego przez AI zajmuje więcej czasu. Na pytanie o zaufanie odpowiedziały 33 244 osoby, a 3,1% z nich zdecydowanie ufa dokładności wyników AI. Zespół, któremu każe się używać narzędzia częściej i który jest z tego rozliczany, jest proszony o ignorowanie tego, co obserwuje codziennie. Dlatego protokół agreguje na poziomie zespołu, trzyma nazwiska poza każdym panelem, traktuje dane o użyciu jako mianownik zamiast wyniku i zbiera własną ocenę zespołu w anonimowej ankiecie przeprowadzanej przed wdrożeniem i ponownie na końcu okna. ### Gdzie to się psuje i co z tym robimy **Punkt odniesienia wzięty po rozpoczęciu wdrożenia** Licencje poszły do pilotażu, potem do wszystkich, a prośba o pomiar przyszła miesiąc później. Pierwszy punkt danych jest już w dołku nauki albo już za nim, więc porównanie przed i po mierzy rozbieg, nie narzędzie. Resztę robi sezonowość: zamrożenie wydań albo okres urlopowy w którymkolwiek oknie przesuwa liczby bardziej niż asystent. Co z tym robimy: Odtwarzamy punkt odniesienia z historii gita i CI dla dwunastu tygodni przed datą pierwszej licencji, osobno dla każdego repozytorium. Reguły wyłączeń ustalamy przed analizą: oznaczamy każdy tydzień z zamrożeniem wydań albo urlopami, żeby dało się go wyłączyć symetrycznie z obu okien, a incydenty, które mogą być skutkiem mierzonych zmian, zostają w danych. Tam, gdzie data wdrożenia różni się między zespołami, każdy zespół dostaje własny punkt odniesienia. Potem sprawdzamy, że zapytania o punkt odniesienia zwracają te same wartości, gdy uruchamia je wasz zespół platformowy. Co zostaje u was: arkusz punktu odniesienia dla każdego zespołu i repozytorium, z zapytaniami, kalendarzem wyłączeń i datą licencji, do której każdy punkt jest zakotwiczony **Przepustowość raportowana bez pary ze stabilnością** Panel pokazuje czas realizacji i scalone pull requesty na tydzień, oba lepsze. Poprawek po scaleniu, revertów i czasu do pierwszej poprawki na nim nie ma, bo nikt o nie nie prosił, a panel dostawcy narzędzia ich nie ma. Dane DORA mówią, że koszt dodatkowego wolumenu zmian pojawia się w stabilności, więc panel pokazuje dokładnie tę połowę, która nie może pójść źle. Co z tym robimy: Definiujemy z góry każdą raportowaną parę i liczymy obie połowy z tych samych repozytoriów i tego samego okna: dla każdej scalonej zmiany liczba dni do późniejszego commita w tych samych liniach, który odwołuje się do błędu, reverta albo hotfixa. Parę raportujemy jako jeden wiersz, żeby zysk w tempie ze stratą w stabilności był widoczny jako jeden wynik, a stratę wyrażamy w godzinach inżynierskich spędzonych na poprawkach, nie tylko w procentach. Co zostaje u was: tabela miar w parach z obiema połowami dla każdego zespołu i okna oraz zapytania, które ją tworzą **Grupą porównawczą jest ten, kto się zgłosił** Pilotaż był otwarty dla każdego chętnego, więc zmierzone osoby to te, które najwięcej oczekiwały od narzędzia, na zadaniach, które same wybrały. Aktualizacja METR z lutego 2026 nazywa dokładnie tę usterkę: programiści odmawiali pracy bez AI, a 30-50% wstrzymało zadania, które bez AI zapowiadały się wolno. Grupa zmierzona i grupa porównawcza różnią się nastawieniem i strukturą zadań, zanim narzędzie cokolwiek zrobi. Co z tym robimy: Przydzielamy zespołami i repozytoriami według fal wdrożenia, które organizacja już ma. Zapisujemy, kto odmówił i dlaczego. Tam, gdzie nie ma struktury fal, porównujemy ten sam zespół z jego własnym punktem odniesienia i wpisujemy to ograniczenie do raportu w pierwszym akapicie, nie w przypisie. Porównujemy podobne zadania dopasowane po typie zgłoszenia i repozytorium oraz raportujemy strukturę zadań w obu grupach, żeby zmiana tego, co ludzie wybrali do pracy, nie uszła za przyspieszenie. Co zostaje u was: zapis przydziału z projektem porównania, dziennikiem odmów i tabelą struktury zadań dla obu grup **Użycie asystenta staje się miarą** Najłatwiej dostępna liczba to ile każda osoba używała asystenta, więc ona trafia na slajd. Zespół szybko zaczyna optymalizować pod nią: podpowiedzi są przyjmowane, a potem przepisywane, sesje otwierane i zostawiane uruchomione. Linia użycia rośnie, linie wyniku nie, a raport stwierdza, że adopcja jest wysoka, a efekt w toku. Tymczasem inżynierowie, których uszeregowano, przestają współpracować z jakimkolwiek przyszłym pomiarem. Co z tym robimy: Dane o użyciu raportujemy osobno, jako kontekst na poziomie zespołu, nigdy jako wynik. Usuwamy z panelu każdy widok dla poszczególnych osób, zanim zostanie udostępniony. Anonimowa ankieta pyta zespół, gdzie narzędzie pomogło, a gdzie kosztowało czas. Te odpowiedzi publikujemy obok liczb. Dostęp do surowych danych jest spisany: kto może je odpytywać, z jaką ziarnistością i czego nigdy się nie eksportuje. Co zostaje u was: specyfikacja panelu z poziomem agregacji, regułami dostępu i kwestionariuszem ankiety oraz wyniki ankiety z obu rund **Liczenie wyniku, który narzędzie zawyża** Linie kodu, commity i pull requesty rosną przy korzystaniu z asystenta, bo generowanie ich to właśnie to, co asystent robi. Zliczenie któregokolwiek z nich po wdrożeniu pokazuje wzrost bez związku z tym, co dotarło do użytkowników. Recenzenci tymczasem wchłaniają dodatkowy wolumen, a ich czas nie pojawia się w żadnym zliczeniu. Co z tym robimy: Definiujemy, co liczy się jako zrobione, zanim otworzy się okno: scalona zmiana, która przetrwała 30 dni bez poprawki w tych samych liniach powiązanej ze zgłoszeniem błędu albo incydentem, oraz pozycja z planu zamknięta w stanie akceptacji z systemu zgłoszeń. Automatyczne rozpoznawanie poprawek ma ograniczenia i raport je wymienia. Dodajemy obciążenie przeglądem na scaloną zmianę jako osobny wiersz, żeby czas, który przesunął się z autora na recenzenta, był widoczny. Potem uruchamiamy definicje na punkcie odniesienia, żeby potwierdzić, że zachowują się tak samo przed i po. Co zostaje u was: arkusz definicji każdej miary wyniku, z zapytaniem, listą wyłączeń i wierszem obciążenia przeglądem ### Co dostajecie - Protokół pomiaru: pytania, pary miar, okno, projekt porównania, poziom agregacji i lista tego, czego celowo się nie mierzy - Arkusz punktu odniesienia dla każdego zespołu i repozytorium za dwanaście tygodni przed wdrożeniem, z zapytaniami i kalendarzem wyłączeń - Panel miar w parach zbudowany na waszych danych z gita, CI i systemu zgłoszeń, z agregacją ustaloną na poziomie zespołu i bez widoku dla poszczególnych osób - Zapis przydziału: grupy porównawcze zespołami albo falami, dziennik odmów i tabela struktury zadań dla obu grup - Kwestionariusz ankiety i wyniki z dwóch anonimowych rund, na początku i na końcu okna pomiaru (pierwsza przed wdrożeniem, jeśli jeszcze się nie zaczęło) - Raport po zamknięciu okna pomiaru mówiący, co się zmieniło, jakim kosztem w poprawkach i obciążeniu przeglądem, czego nie dało się zmierzyć i dlaczego, napisany tak, żeby zarząd i zespół przeczytali tę samą wersję - Przekazanie: zapytania, definicje i panel zostają u waszego zespołu platformowego, żeby ten sam pomiar dało się powtórzyć co kwartał ### Jak pracujemy 1. **1. Protokół i punkt odniesienia** (Tydzień 1-2): Uzgadniamy pytania, na które chcą odpowiedzi zarząd i zespół, wybieramy pary miar i odtwarzamy punkt odniesienia z historii gita i CI za dwanaście tygodni przed pierwszą licencją. Jeśli wdrożenie jeszcze się nie zaczęło, tu ustalamy też strukturę fal i grupy porównawcze. 2. **2. Instrumentacja** (Tydzień 2-3): Budujemy zapytania do waszych repozytoriów, CI i systemu zgłoszeń, uruchamiamy je na punkcie odniesienia, żeby sprawdzić ich zachowanie, oraz stawiamy panel z agregacją na poziomie zespołu oraz spisanymi regułami dostępu. Przeprowadzamy pierwszą ankietę. 3. **3. Okno pomiaru** (Tydzień 3-15): Panel działa przez osiem do dwunastu tygodni. Co miesiąc sprawdzamy dane pod kątem luk, zamrożeń i incydentów do oznaczenia. Nie raportujemy wyników cząstkowych, bo migawka z czterech tygodni czyta się jako porażka albo jako czysty zysk, zależnie od tego, kiedy ją wziąć. 4. **4. Raport i przekazanie** (Tydzień 15-16): Przeprowadzamy drugą ankietę, liczymy każdą parę dla obu okien i obu grup i piszemy raport z ograniczeniami w pierwszym akapicie. Zapytania, definicje i panel trafiają do waszego zespołu platformowego z instrukcją na następny kwartał. ### FAQ **Q: Wdrożenie było wiele miesięcy temu. Czy efekt da się jeszcze zmierzyć?** Tak, ze słabszym projektem i uczciwym raportem. Punkt odniesienia można odtworzyć z historii gita i CI, jeśli zachowały się potrzebne dane i da się ustalić początek korzystania z AI, także poza firmowymi licencjami; wtedy porównanie przed i po jest dostępne nawet bez wcześniejszego planu. Traci się grupę porównawczą, chyba że część zespołów przyjęła narzędzie później niż inne; wtedy te zespoły nią zostają. Raport mówi, który projekt zastosowano i czego nie może wykluczyć. **Q: Czy potrzebujemy grupy kontrolnej?** Pomiar jest z nią mocniejszy, a wiele organizacji już ją ma w postaci fal wdrożenia. Tam, gdzie każdy zespół przyjął narzędzie tego samego dnia, porównaniem jest własny punkt odniesienia zespołu z sezonowością oznaczoną i wyłączoną symetrycznie. Czego nigdy nie robimy, to używanie ochotników jako którejkolwiek z grup, bo aktualizacja METR z lutego 2026 dokumentuje, jak samoselekcja decyduje o wyniku, zanim narzędzie cokolwiek zrobi. **Q: Jakie narzędzia musimy kupić?** Żadnych. Miary pochodzą z gita, logów CI i systemu zgłoszeń, które już prowadzicie, a panel jest na nich zbudowany. Dane o użyciu asystenta z konsoli dostawcy są mile widziane jako mianownik, ale żaden wynik na panelu nie pochodzi z panelu dostawcy. **Q: Czy ktoś zobaczy liczby dla pojedynczych osób?** W raportach i na panelu nie. Agregacja jest ustalona na poziomie zespołu w specyfikacji panelu, a widoki dla poszczególnych osób są usuwane, zanim cokolwiek zostanie udostępnione. Dostęp do surowych danych, które pozwalają rozpoznać osoby, mają tylko osoby wskazane w regułach dostępu, z zapisaną ziarnistością. To decyzja projektowa z powodem: ranking osób zamienia miarę w cel i kończy współpracę zespołu z jakimkolwiek przyszłym pomiarem. **Q: Co, jeśli wynik jest zerowy albo ujemny?** Wtedy to jest wynik, a raport mówi, gdzie siedzi koszt: w poprawkach po scaleniu, w obciążeniu przeglądem albo w strukturze zadań, która się przesunęła. Ujemny wynik na mierze w parze jest dla zarządu bardziej użyteczny niż dodatni na pojedynczej, bo nazywa, co zmienić. Opublikowane wyniki mają oba znaki, więc żaden z nich nie jest zaskoczeniem. **Q: Czy to biznesowe uzasadnienie zwrotu z inwestycji w narzędzie, którego jeszcze nie kupiliśmy?** Nie. Protokół mierzy wdrożenie, które trwa albo już się zakończyło, na własnych danych zespołu. Prognoza biznesowa przed decyzją to inna praca z innymi danymi wejściowymi i ta strona jej nie oferuje. **Q: Czym to się różni od panelu z miarami DORA?** Cztery miary DORA w nim są, jako dwie z par. Protokół dodaje punkt odniesienia zakotwiczony w dacie licencji, regułę parowania, która nie pozwala raportować przepustowości samej, projekt porównania zespołami, spisaną listę tego, czego się nie liczy, oraz ankietę, która stawia własną ocenę zespołu obok liczb. Panel pokazuje bieżącą wartość; protokół mówi, z czym ta wartość jest porównywana i dlaczego. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/analityka-produktu-ai ### Źródła - Becker, Rush, Barnes, Rein (METR), Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (arXiv:2507.09089, lipiec 2025): https://arxiv.org/abs/2507.09089 - METR, Measuring AI uplift: korekta metodyki i dane z końca 2025 (24 lutego 2026): https://metr.org/blog/2026-02-24-uplift-update/ - Cui, Demirer, Jaffe, Musolff, Peng, Salz, The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers (Management Science, 2026): https://www.microsoft.com/en-us/research/publication/the-effects-of-generative-ai-on-high-skilled-work-evidence-from-three-field-experiments-with-software-developers/ - Google Cloud, Announcing the 2025 DORA Report: State of AI-assisted Software Development: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report - DORA, The ROI of AI-assisted Software Development (v.2026.1, kwiecień 2026): https://dora.dev/ai/roi/report/ - InfoQ, New DORA Report Claims Strong Engineering Foundations Drive AI Return on Investment (maj 2026): poglądowy przykład odsetka nieudanych zmian i kwota 344 000 USD: https://www.infoq.com/news/2026/05/dora-roi-ai-assisted-dev-report/ - Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, The SPACE of Developer Productivity: There's more to it than you think (ACM Queue, 2021): https://www.microsoft.com/en-us/research/publication/the-space-of-developer-productivity-theres-more-to-it-than-you-think/ - Stack Overflow, 2025 Developer Survey, sekcja AI (49 009 odpowiedzi; odsetki liczone od osób, które odpowiedziały na dane pytanie): https://survey.stackoverflow.co/2025/ai - The Register, Devs gripe about having AI shoved down their throats: pracodawcy uwzględniający indywidualne użycie AI w ocenach okresowych (19 listopada 2025): https://www.theregister.com/2025/11/19/ai_force_feeding/ --- ## Niezależne porównanie narzędzi do AI code review: protokół, który uruchomicie na własnym repozytorium **URL:** https://23minds.com/pl/przewodniki/niezalezne-porownanie-narzedzi-ai-code-review > Porównanie pokazuje, które narzędzie wykrywa błędy w waszym kodzie, ile zostawia błędnych uwag i ile kosztuje na pull request. Pomiar biegnie na waszych własnych pull requestach: z defektami wstrzykniętymi przez was i z czystymi zmianami, a komentarze ocenia inżynier, który nie wie, które narzędzie je napisało. Zamiast pytania, które narzędzie jest najlepsze, protokół odpowiada na pytanie, które narzędzie ma rację o waszym kodzie. ### Podsumowanie 23Minds prowadzi niezależne porównania narzędzi do AI code review dla zespołów, które wybierają albo wymieniają takie narzędzie. Firma nie sprzedaje narzędzia do przeglądu kodu i nie bierze prowizji od żadnego dostawcy. Porównanie używa jednego stałego zestawu pull requestów zespołu, częściowo z wstrzykniętymi defektami, częściowo czystych, uruchamia każde kandydujące narzędzie na tym samym zestawie z tą samą ustaloną konfiguracją i każe inżynierowi ocenić każdy komentarz bez wiedzy, które narzędzie go napisało. Wynik to precyzja, czułość i szum dla każdej klasy ustalenia, udział komentarzy poza diffem, koszt na pull request i zmiana czasu recenzenta, dla każdego narzędzia na tym samym repozytorium. Zespół zatrzymuje protokół, rejestr wstrzykniętych defektów, arkusz ocen i rekomendację z uzasadnieniem i może powtórzyć cały pomiar, gdy zmieni się narzędzie albo model. ### Dla kogo to jest - CTO i szefowie inżynierii, którzy muszą wybrać jedno narzędzie do AI code review dla całej organizacji i mają do dyspozycji tylko rankingi dostawców - Zespoły platformowe i zespoły usprawniające pracę programistów, które mają uzasadnić subskrypcję per stanowisko czymś więcej niż demo - Menedżerowie inżynierii, których recenzenci skarżą się, że obecne narzędzie jest rozwlekłe, komentuje kod, którego nikt nie zmieniał, albo myli się z pewnością siebie - Zespoły, które prowadzą równolegle dwa albo trzy narzędzia i płacą za wszystkie, bo nikt nie zmierzył, które zasługuje na swoje miejsce ### Czego brakuje w porównaniach od dostawców Wyszukiwanie najlepszego narzędzia do AI code review zwraca listy pisane przez firmy, które je sprzedają, a na takiej liście autor zwykle jest pierwszy. Benchmarki za tymi listami mają jeden kształt: dostawca wybiera pull requesty, dostawca wstrzykuje albo oznacza błędy, model dostawcy ocenia komentarze, a publikowaną miarą jest liczba znalezionych znanych błędów. Miarą, której te listy nie podają, jest liczba błędnych komentarzy. Ta asymetria zgadza się z tym, co zgłaszają praktycy. W dyskusjach inżynierów o tych narzędziach powtarzają się trzy zastrzeżenia: rozwlekłość, komentarze do kodu spoza pull requesta i ustalenia opisujące zachowanie, którego kod nie ma. Wszystkie trzy dotyczą precyzji, a precyzja to liczba, której listy dostawców nie pokazują. Otwarty benchmark w tej kategorii, Code Review Bench od Martian, publikuje zbiór danych, prompty sędziego, pipeline i definicje precyzji oraz czułości. Przy starcie w lutym 2026 autorzy benchmarku podali, że żadne narzędzie nie znalazło więcej niż 63% ze 137 znanych problemów w zbiorze. Mówią też wprost, że zbiór wzorcowy zawiera błędy i że statyczny zbiór mógł zostać zobaczony przez narzędzia w treningu. Nawet uczciwy benchmark mierzy własne repozytoria. Opublikowany zbiór to projekty open source w pięciu językach, z własnymi konwencjami i wielkością pull requestów; waszego rozkładu defektów, waszej kultury przeglądu i konfiguracji, którą naprawdę byście uruchomili, nie ma w żadnym z nich. Jedyne porównanie, które odpowiada na wasze pytanie zakupowe, to porównanie na waszym kodzie. ### Decydujące miary i dlaczego trzeba je mierzyć na własnym repozytorium Platforma analizy statycznej Google, Tricorder, ustaliła roboczą definicję szumu, której narzędzia do przeglądu kodu używają do dziś: ustalenie jest skutecznie fałszywym alarmem, jeśli programista po jego zobaczeniu nie podejmuje żadnego działania. Analizator, w którym udział takich alarmów przekracza 10%, jest wyłączany z przeglądu kodu. Ten próg mierzy się na zachowaniu programistów w jednym repozytorium, dlatego nie da się go skopiować ze strony dostawcy. Druga liczba, która zmienia decyzję, to wpływ narzędzia na sam przegląd. Badanie przemysłowe narzędzia do przeglądu opartego na open source PR Agent (Cihan i współautorzy, ICSE SEIP 2025) objęło 4 335 pull requestów w trzech projektach: 73,8% automatycznych komentarzy zostało oznaczonych jako rozwiązane, a średni czas zamknięcia pull requesta wzrósł z 5 godzin 52 minut do 8 godzin 20 minut. Większość komentarzy została rozwiązana, a przegląd trwał dłużej. Obie liczby muszą być w arkuszu. Każda miara poniżej jest zdefiniowana raz i liczona dla każdej klasy ustalenia osobno, bo narzędzie, które ma rację o sprawdzaniu wartości pustych, a myli się o współbieżności, to dwa różne narzędzia, zależnie od tego, jakie macie defekty. - Czułość: udział wstrzykniętych defektów, które narzędzie znalazło, dla każdej klasy osobno, żeby klasy, których narzędzie nigdy nie widzi, były nazwane, a nie uśrednione. - Precyzja: udział komentarzy ocenionych jako trafne wśród wszystkich komentarzy, dla każdej klasy ustalenia. - Szum na czystych pull requestach: komentarze na zmianach bez wstrzykniętego defektu, ocenione jako nietrafne albo bez działania po stronie autora, liczone na pull request. - Udział komentarzy poza diffem: komentarze, których tematem jest kod, którego pull request nie dotknął, z osobnym oznaczeniem, czy ustalenie wynika ze zmiany. - Zweryfikowane fałszywe ustalenia: komentarze twierdzące o kontrakcie, zachowaniu albo podatności, których kod nie ma, sprawdzone z kodem. - Koszt na pull request z faktury. GitHub rozlicza przegląd Copilota w kredytach AI zależnych od poziomu nakładu; CodeRabbit rozlicza per programista z godzinowym limitem przeglądów (cenniki wskazane w źródłach). Ile kosztuje jeden pull request, wiadomo dopiero po przebiegu. - Czas recenzenta: minuty, które człowiek spędza nad pull requestem z narzędziem i bez niego, oraz czas zamknięcia w tym samym oknie, mierzone w pilotażu na bieżących zmianach. ### Protokół Protokół ustala wszystko, co benchmarki dostawców zostawiają dostawcy. Zestaw pull requestów jest wasz, zamrożony, zanim uruchomi się jakiekolwiek narzędzie. Defekty wstrzykuje inżynier, który przed przebiegiem zapisuje każdy w rejestrze z klasą i lokalizacją. Czyste pull requesty to prawdziwe scalone zmiany, które drugi inżynier przeczytał ponownie i potwierdził. Każde narzędzie działa na tym samym zestawie w tym samym tygodniu, w konfiguracji, którą dokumentacja dostawcy opisuje jako zalecaną. Żadne narzędzie nie widzi komentarzy innego. Ocena odbywa się bez znajomości autora komentarza. Komentarze są pozbawione nazwy narzędzia i formatowania, przetasowane i oceniane przez inżyniera, który zna kod, wobec rejestru wstrzykniętych defektów i samego kodu. Sędzią jest człowiek, bo opublikowane benchmarki dopasowują komentarze do poprawek modelem językowym, a sędzia z tej samej rodziny modeli co oceniane narzędzie może faworyzować jego styl. Drugi oceniający ocenia próbkę, więc zgodność między oceniającymi jest liczbą w arkuszu, a nie założeniem. Wpływ na bieżącą pracę mierzy osobny pilotaż: przez okno przebiegu rekomendowane narzędzie komentuje bieżące pull requesty, recenzenci zapisują minuty na próbce, a czas zamknięcia porównuje się z tygodniami bazowymi przed pilotażem. | Co jest mierzone | Jak | Próg albo reguła decyzji | | --- | --- | --- | | Czułość dla każdej klasy defektu | Znalezione wstrzyknięte defekty / wstrzyknięte defekty, osobno dla klas: logika, współbieżność, obsługa wejścia, bezpieczeństwo, kontrakt API, luka w testach | Klasy poniżej progu ustalonego przez zespół są wypisane w rekomendacji jako niepokryte, nigdy uśrednione | | Precyzja dla każdej klasy ustalenia | Komentarze ocenione jako trafne / wszystkie komentarze, dla każdej klasy, oceniane wobec kodu bez znajomości autora | Klasa, w której udział skutecznie fałszywych alarmów przekracza 10% (reguła Tricordera), jest wyłączana w konfiguracji narzędzia | | Szum na czystych pull requestach | Nietrafne albo bezczynne komentarze na czysty pull request i udział czystych pull requestów z co najmniej jednym takim komentarzem | Raportowany obok czułości; narzędzie, które znajduje więcej i mówi więcej, jest oceniane na obu | | Udział komentarzy poza diffem | Komentarze o liniach, których pull request nie zmienił / wszystkie komentarze, z oznaczeniem, czy ustalenie wynika ze zmiany | Raportowany dla każdego narzędzia; konfiguracja, która go zmniejsza, jest zapisywana | | Zweryfikowane fałszywe ustalenia | Komentarze twierdzące o zachowaniu, którego kod nie ma, potwierdzone przez przeczytanie kodu | Liczone osobno od zwykłych pominięć; jedno na pull request jest osobną pozycją w rekomendacji | | Koszt na pull request | Faktura za okres przebiegu albo zużyte kredyty przeliczone po cenie kredytu, z abonamentem policzonym proporcjonalnie do dni przebiegu, podzielone przez liczbę pull requestów w zestawie | Porównywany przy prawdziwym wolumenie pull requestów zespołu, nie po cenie z cennika | | Czas recenzenta i czas zamknięcia | Minuty zapisane przez recenzentów w pilotażu na bieżących pull requestach oraz czas do scalenia w oknie pilotażu, wobec tygodni bazowych | Narzędzie, które wydłuża czas zamknięcia, uzasadnia to tylko wykrywaniem defektów w klasach ważnych dla zespołu; rekomendacja podaje oba wymiary | | Zgodność oceniających | Drugi inżynier ocenia próbkę; zgodność dla każdej klasy | Poniżej uzgodnionego poziomu definicje klas są przepisywane, a próbka oceniana ponownie, zanim powstanie jakikolwiek ranking | ### Jak uruchomić to na własnym repozytorium Protokół jest zaprojektowany tak, żeby zespół powtarzał go bez pomocy z zewnątrz, bo odpowiedź zmienia się za każdym razem, gdy dostawca podmienia model. Wielkość zestawu wynika z liczby klas defektów do pokrycia i z pewności, jakiej potrzebujecie od wyniku. Zestaw z rejestrem defektów i czystą grupą kontrolną daje liczbę; nieoznaczone pull requesty, nawet liczne, dają tylko wrażenie. - Weźcie pull requesty z ostatniego kwartału, które odpowiadają waszemu prawdziwemu rozkładowi wielkości i języków, a nie te najciekawsze. - Wstrzykujcie defekty ręcznie i zapisujcie każdy przed przebiegiem: plik, linia, klasa i zdanie, które musiałby zawierać trafny komentarz. - Zostawcie w zestawie czyste pull requesty. Bez nich szum jest niewidoczny i każde narzędzie wygląda na ostrożne. - Skonfigurujcie każde narzędzie raz według jego dokumentacji i zamroźcie konfigurację. Strojenie w trakcie przebiegu zamienia porównanie w demo. - Uruchomcie wszystkie narzędzia w tym samym tygodniu na tych samych commitach i zapiszcie model albo wersję, którą raportuje każdy dostawca. - Usuńcie tożsamość narzędzia przed oceną i trzymajcie oceniającego z dala od osoby, która konfigurowała narzędzia. - Wpiszcie koszt przebiegu do arkusza z faktury, na pull request, obok liczby defektów wykrytych za tę cenę. - Gdy narzędzie ogłosi zmianę modelu, uruchomcie ten sam zestaw ponownie i porównajcie arkusze. ### Co dostaje zespół i jak to się ma do audytu Zlecenie kończy się dokumentem protokołu, zamrożonym zestawem z rejestrem defektów, arkuszem ocen ze zgodnością oceniających, jednym arkuszem wyników dla każdego narzędzia i rekomendacją, która nazywa narzędzie, konfigurację, niepokryte klasy defektów oraz koszt narzędzia przy waszym wolumenie. Rekomendacja mówi dlaczego, w liczbach z arkusza, żeby późniejszy zespół mógł nie zgodzić się z rozumowaniem, a nie z wnioskiem. Narzędzie wybrane w ten sposób nadal przegląda diff. Porównanie narzędzia do AI code review z niezależnym audytem na tej stronie opisuje to, czego narzędzie nie widzi: architekturę, testy i granice zaufania całego systemu, także przed jego uruchomieniem. Arkusz wyników zasila ten audyt, bo klasy, których narzędzie nie pokrywa, biorą na siebie praktyki Audyt kodu pisanego przez AI i Pokrycie testowe. ### Gdzie to się psuje i co z tym robimy **Czułość na zbiorze dostawcy, precyzja na niczyim** Benchmark dostawcy wstrzykuje błędy do pull requestów i liczy, ile z nich narzędzie znajduje. Nikt nie uruchamia tego samego narzędzia na pull requestach bez wstrzykniętego błędu, więc komentarze, które tam zostawia, czyli te, które wasi recenzenci będą czytać codziennie, nigdy nie wchodzą do wyniku. Narzędzie, które mówi najwięcej, wygrywa publikowaną liczbę, a zespół, który je kupuje, dziedziczy szum. Co z tym robimy: Budujemy zestaw z czystą grupą kontrolną prawdziwych scalonych zmian przeczytanych ponownie przez drugiego inżyniera i liczymy nietrafne komentarze na czysty pull request obok czułości na wstrzykniętych defektach. Tam, gdzie w klasie ustalenia udział skutecznie fałszywych alarmów przekracza 10% (reguła Tricordera), wyłączamy tę klasę w konfiguracji narzędzia i uruchamiamy zestaw ponownie, żeby potwierdzić, ile czułości przy tym ubyło. Co zostaje u was: arkusz wyników dla każdego narzędzia z czułością i szumem obok siebie dla każdej klasy oraz konfiguracja, która wyłącza szumiącą klasę **Komentarze do kodu, którego pull request nie dotknął** Narzędzia, które czytają całe repozytorium dla kontekstu, także je komentują. Pull request zmieniający jedną funkcję wraca z uwagami do modułu wokół niej, a recenzent nie umie z komentarza rozpoznać, czy ustalenie dotyczy zmiany, czy kodu, który jest na produkcji od dwóch lat. Narzędzie robi to, na co pozwala mu okno kontekstu; procesowi przeglądu nikt nie powiedział, żeby się tego spodziewał. Co z tym robimy: Każdy komentarz w arkuszu ocen oznaczamy tym, czy jego temat leży w diffie i czy ustalenie wynika z tej zmiany, bo uwaga do niezmienionej linii bywa skutkiem zmiany obok. Raportujemy udział komentarzy poza diffem dla każdego narzędzia i testujemy opcje konfiguracji ograniczające zakres, które dokumentuje każdy dostawca. Ustalenia poza diffem, które są prawdziwe i nie wynikają ze zmiany, trafiają na osobną listę zadań dla właściciela utrzymania, a nie do pull requesta. Co zostaje u was: udział komentarzy poza diffem dla każdego narzędzia przed konfiguracją i po niej oraz lista zweryfikowanych ustaleń poza diffem z właścicielem **Ustalenie opisujące zachowanie, którego kod nie ma** Komentarz czyta się jak precyzyjny raport o defekcie: funkcja, która rzekomo ignoruje błąd, nagłówek, który rzekomo nie jest walidowany. Kod nie robi żadnej z tych rzeczy, ale zdanie jest płynne i konkretne, więc autor spędza dwadzieścia minut na udowadnianiu, że czegoś nie ma, albo, gorzej, zmienia działający kod, żeby zadowolić komentarz. Inżynierowie opisują to jako zmyślanie przez narzędzie i jest to najdroższy rodzaj pomyłki, bo najbardziej przypomina trafienie. Co z tym robimy: Oceniamy wobec kodu, a nie wobec komentarza, więc zweryfikowane fałszywe ustalenie jest osobną klasą w arkuszu z własnym licznikiem dla każdego narzędzia. Najbardziej przekonujące błędne ustalenia z przebiegu zachowujemy jako zestaw szkoleniowy dla recenzentów, żeby zespół nauczył się, jak wygląda pewne siebie i błędne z tego narzędzia, zanim ono wejdzie do użycia. Co zostaje u was: liczba zweryfikowanych fałszywych ustaleń dla każdego narzędzia na sto komentarzy oraz opisany zestaw najbardziej przekonujących błędnych ustaleń z przebiegu **Model oceniający model z własnej rodziny** Opublikowane benchmarki dopasowują komentarze narzędzi do poprawek ludzi modelem językowym, bo ręczna ocena tysięcy komentarzy jest wolna. Sędzia z tej samej rodziny modeli co oceniane narzędzie może faworyzować jego styl, a wynik przesuwa się razem z wersją modelu sędziego. Zespół, który kopiuje liczbę, nie umie powiedzieć, ile w niej było sędziego. Co z tym robimy: Oceniamy bez znajomości autora komentarza, inżynierem, który zna kod, a drugi inżynier ocenia próbkę, więc zgodność między oceniającymi jest mierzona dla każdej klasy. Tylko tam, gdzie zgodność jest wystarczająco wysoka, pozwalamy modelowi wstępnie posortować komentarze, a jego sortowanie sprawdzamy z ludzką próbką, zanim zostanie policzone. Co zostaje u was: zgodność oceniających dla każdej klasy na próbce oraz reguła, kiedy wolno użyć wstępnego sortowania modelem **Rozwiązane komentarze rosną, czas przeglądu rośnie, nikt nie patrzy na drugą liczbę** Badanie przemysłowe narzędzia do przeglądu opartego na PR Agent znalazło 73,8% automatycznych komentarzy oznaczonych jako rozwiązane i czas zamknięcia pull requesta wydłużony z 5 godzin 52 minut do 8 godzin 20 minut. Dashboard z rozwiązanymi komentarzami czyta się jak sukces; czas zamknięcia siedzi w innym narzędziu. Recenzenci odczuwają opóźnienie, dashboard go nie pokazuje. Co z tym robimy: W pilotażu na bieżących pull requestach zapisujemy minuty recenzentów na próbce i bierzemy czas zamknięcia z systemu kontroli wersji dla okna pilotażu i tygodni bazowych przed nim. Narzędzie, które wydłuża czas zamknięcia, rekomendujemy tylko tam, gdzie wykrywa defekty w klasach ważnych dla zespołu, a rekomendacja podaje wprost, ile opóźnienia przypada na wykryte defekty. Co zostaje u was: minuty recenzentów i czas zamknięcia dla każdego narzędzia wobec punktu bazowego, obok defektów wykrytych za każdą dodaną godzinę ### Co dostajecie - Dokument protokołu: budowa zestawu, zasady wstrzykiwania defektów, zamrożenie konfiguracji, procedura oceny bez znajomości autora, definicje miar i progi - Zamrożony zestaw pull requestów z rejestrem wstrzykniętych defektów (plik, linia, klasa, oczekiwane ustalenie) i czystą grupą kontrolną z potwierdzeniem drugiego czytającego - Arkusz ocen z każdym komentarzem, jego klasą, werdyktem i oceniającym; zgodność oceniających dla każdej klasy na próbce - Arkusz wyników dla każdego narzędzia: czułość i precyzja dla każdej klasy, szum na czystych pull requestach, udział komentarzy poza diffem, liczba zweryfikowanych fałszywych ustaleń, koszt na pull request, minuty recenzentów i czas zamknięcia wobec punktu bazowego - Rekomendacja z uzasadnieniem: narzędzie, konfiguracja, niepokryte klasy defektów oraz koszt narzędzia przy waszym wolumenie - Instrukcja ponownego przebiegu, żeby zespół powtórzył pomiar po zmianie modelu u dostawcy i porównał arkusze ### Jak pracujemy 1. **1. Zakres i budowa zestawu** (Tydzień 1): Uzgadniamy klasy defektów ważne dla waszego kodu, wybieramy pull requesty z waszej niedawnej historii, wstrzykujemy defekty i piszemy rejestr, a drugi inżynier potwierdza czystą grupę kontrolną. Nic nie rusza, dopóki zestaw nie jest zamrożony. 2. **2. Przebiegi narzędzi** (Tydzień 2): Konfigurujemy każdego kandydata według jego dokumentacji, zapisujemy model albo wersję, którą raportuje, uruchamiamy wszystkie na tych samych commitach w tym samym tygodniu i zbieramy każdy komentarz razem ze zużyciem kredytów albo fakturą za przebieg. 3. **3. Ocena i pilotaż** (Tydzień 2-3): Usuwamy tożsamość i formatowanie z komentarzy, oceniamy je wobec kodu i rejestru, a drugi inżynier ocenia próbkę. Równolegle biegnie pilotaż na bieżących pull requestach, z minutami recenzentów i czasem zamknięcia wobec punktu bazowego. 4. **4. Wyniki i rekomendacja** (Tydzień 3-4, zależnie od liczby narzędzi i klas): Składamy arkusz wyników dla każdego narzędzia. Tam, gdzie liczby tego wymagają, uruchamiamy zestaw ponownie z wyłączonymi szumiącymi klasami. Przekazujemy rekomendację, protokół, rejestr i instrukcję ponownego przebiegu. ### FAQ **Q: Które narzędzie do AI code review jest najlepsze?** Na waszym repozytorium, z waszym rozkładem defektów i waszą konfiguracją, nie wiemy tego, dopóki zestaw nie zostanie uruchomiony. Nie wie tego też nikt, kto publikuje ranking. Otwarty benchmark w tej kategorii podał przy starcie w lutym 2026, że żadne narzędzie nie znalazło więcej niż 63% jego znanych problemów, a jego autorzy mówią, że zbiór wzorcowy ma błędy. Protokół z tej strony istnieje po to, żeby odpowiedzią był arkusz z waszego kodu, a nie lista od dostawcy. **Q: Czy 23Minds sprzedaje albo odsprzedaje narzędzie do przeglądu kodu?** Nie. Nie sprzedajemy narzędzia do przeglądu kodu, nie bierzemy opłat za polecenie ani prowizji od żadnego dostawcy, a rekomendacja jest napisana w liczbach z arkusza wyników, więc da się ją z nimi sprawdzić. Jeśli rekomendowane narzędzie zmieni model, instrukcja ponownego przebiegu pozwala sprawdzić je jeszcze raz bez nas. **Q: Ilu pull requestów potrzebuje zestaw?** Tylu, żeby każdą ważną dla was klasę defektu pokryć kilka razy, plus czysta grupa kontrolna podobnej wielkości. Wielkość zależy od liczby klas i od pewności, jakiej potrzebujecie od wyniku; otwarty benchmark w źródłach pracuje na 50 wybranych pull requestach z pięciu projektów. Oznaczony rejestr i potwierdzona czysta grupa dają liczbę, nieoznaczone pull requesty dają wrażenie. **Q: Czy ocenę może zrobić model zamiast inżyniera?** Wstępne sortowanie tak, gdy zgodność dwóch ludzkich oceniających została zmierzona na próbce, a sortowanie modelu sprawdzone z nią. Ostateczne werdykty nie. Opublikowane benchmarki używają modelu językowego jako sędziego, a sędzia z tej samej rodziny co narzędzie może faworyzować jego styl. W każdym przebiegu zostawiamy ludzką próbkę, żeby ta skłonność była zmierzona, a nie założona. **Q: Mamy już SonarQube albo Semgrep. Czy należą do porównania?** Tak, jako wiersz bazowy. Narzędzia deterministyczne mają znaną precyzję w pokrywanych klasach i koszt niezależny od pull requesta. Uruchomienie ich na tym samym zestawie pokazuje, które ustalenia narzędzia oparte na modelach dokładają ponad to, co już macie, a tylko taka czułość uzasadnia nową subskrypcję. **Q: Co znaczy koszt na pull request, gdy narzędzie jest wyceniane per stanowisko?** Cennik CodeRabbit rozlicza per programista z godzinowym limitem przeglądów; GitHub rozlicza przegląd Copilota w kredytach AI zależnych od nakładu przeglądu (oba cenniki w źródłach, ze stanem na dzień publikacji). W żadnym z nich cennik nie mówi, ile kosztuje jeden pull request przy waszym wolumenie. Bierzemy fakturę za okres przebiegu albo zużyte kredyty przeliczone po cenie kredytu, abonament liczymy proporcjonalnie do dni przebiegu, dzielimy przez liczbę pull requestów w zestawie i stawiamy to obok liczby wykrytych defektów. **Q: Czy wybrane narzędzie zastępuje niezależny audyt kodu pisanego przez AI?** Nie. Narzędzie przegląda diffy; audyt obejmuje architekturę, testy i granice zaufania całego systemu, także przed jego uruchomieniem. Arkusz wyników mówi, których klas defektów narzędzie nie pokrywa, a te klasy biorą na siebie praktyki Audyt kodu pisanego przez AI i Pokrycie testowe z tej strony. Porównanie narzędzia do przeglądu z audytem na tej stronie opisuje ten podział szczegółowo. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/pokrycie-testowe ### Źródła - Martian, Code Review Bench v0: niezależny benchmark narzędzi do AI code review, otwarty zbiór i pipeline, deklarowane ograniczenia zbioru wzorcowego: https://withmartian.com/post/code-review-bench-v0 - withmartian/code-review-benchmark na GitHubie: 50 PR-ów z 5 projektów open source, 137 komentarzy wzorcowych przy starcie w lutym 2026 i 173 po późniejszych zmianach, definicje precyzji i czułości, zastrzeżenie o wycieku do danych treningowych: https://github.com/withmartian/code-review-benchmark - Cihan i in., Automated Code Review In Practice (ICSE SEIP 2025, arXiv 2412.18531): 4335 PR-ów, 73,8% rozwiązanych komentarzy, czas zamknięcia z 5 h 52 min do 8 h 20 min: https://arxiv.org/abs/2412.18531 - Zhang i in., Code Review Agent Benchmark (arXiv 2603.23448): agenci przeglądu rozwiązują około 40% zadań wyprowadzonych z ludzkich przeglądów: https://arxiv.org/abs/2603.23448 - Software Engineering at Google, rozdział 20, Static Analysis: definicja efektywnie fałszywego ustalenia, próg 10%, sygnały Not useful i Please fix: https://abseil.io/resources/swe-book/html/ch20.html - GitHub Docs, Copilot code review: rozliczanie w kredytach AI według poziomu wysiłku, kontekst całego repozytorium, brak gwarancji wykrycia wszystkich problemów: https://docs.github.com/en/copilot/concepts/code-review/code-review - Cennik CodeRabbit: rozliczanie per deweloper z limitem przeglądów na godzinę, darmowe przeglądy dla repozytoriów publicznych: https://www.coderabbit.ai/pricing - Przykład rankingu pisanego przez dostawcę: CodeRabbit o swojej pozycji w benchmarku Martian: https://www.coderabbit.ai/blog/coderabbit-tops-martian-code-review-benchmark - Przykład rankingu pisanego przez dostawcę: Kilo o tym samym benchmarku, z własnym narzędziem na pierwszym miejscu: https://blog.kilo.ai/p/martians-independent-benchmark-tested --- ## Polityka wnoszenia kodu pisanego z AI dla zespołów inżynierskich: kto podpisuje jego pochodzenie **URL:** https://23minds.com/pl/przewodniki/polityka-wnoszenia-kodu-z-ai > Polityka wnoszenia kodu pisanego z AI (AI contribution policy) to dokument, który mówi, kto bierze odpowiedzialność za kod napisany przez model, jak to pochodzenie jest deklarowane w pull requeście i co recenzent może zamknąć bez czytania. Ta strona zawiera szkielet takiej polityki ze sposobem sprawdzenia każdej reguły oraz decyzje, które opublikowane projekty podjęły przed wami. ### Podsumowanie 23Minds pisze polityki wnoszenia kodu pisanego z AI dla zespołów inżynierskich i projektów open source, razem z szablonem pull requesta, konwencją trailerów w commitach i kontrolami w repozytorium. Polityka rozstrzyga cztery pytania: kto podpisuje kod, którego nie napisał ręcznie, gdzie deklaruje się pomoc AI, jakie obowiązki ma autor przed przeglądem i co recenzent może odrzucić bez czytania. Polityka określa obowiązki autora, a kontrole w repozytorium blokują zmiany, które nie spełniają sprawdzalnych wymagań; przy każdej regule wskazano, kogo obowiązuje i czy sprawdza ją CI, czy recenzent. Zespół dostaje dokument, szablon, konfigurację i audyt próbki pull requestów po pierwszym cyklu. ### Dla kogo to jest - CTO i wiceprezesi ds. inżynierii, których zespoły już wdrażają kod pisany z AI i nie mają spisanej reguły, kto go podpisuje - Opiekunowie projektów open source, którzy dostają pull requesty z kodem pisanym przez AI i szukają reguł do egzekwowania zamiast sporów - Menedżerowie inżynierii, od których dział prawny albo bezpieczeństwa chce dokumentu opisującego, jak kod pisany z AI wchodzi do bazy kodu - Zespoły zarządzania dostawcami, które odbierają dostawy od wykonawców pracujących z agentami kodującymi ### Cztery pytania, na które polityka musi odpowiedzieć Spory o pochodzenie kodu w 2026 roku dotyczą odpowiedzialności, nie narzędzi. Pytanie pada z dwóch stron: opiekun chce wiedzieć, kto odpowiada za pull request na tysiące linii napisanych przez AI, a inżynier, który odziedziczył niemal w całości tak napisany projekt, chce wiedzieć, czyje nazwisko na nim widnieje. Badanie z września 2026 obejmujące 281 polityk AI w 2 000 najwyżej ocenianych repozytoriów na GitHubie i w grupie znanych projektów (Hora, Robbes i Zacchiroli) ustaliło, że 83,3% z nich dopuszcza AI we wkładzie w kod, a 48,8% wymaga ujawnienia. Działającą częścią polityki są jej warunki, a użyteczna polityka to lista warunków ze sposobem sprawdzenia każdego z nich. - Kto podpisuje. Człowiek, który otwiera pull request, poświadcza pochodzenie na podstawie Developer Certificate of Origin albo firmowego odpowiednika i bierze z tym błąd, regresję i pytanie o licencję. Narzędzie nigdy nie podpisuje: polityka jądra Linuksa stwierdza, że agenci AI nie mogą dodawać tagów Signed-off-by, bo tylko człowiek może poświadczyć DCO. - Co się deklaruje i gdzie. Jeden schemat na organizację: trailer w commicie, pole w szablonie pull requesta albo etykieta, wybrany świadomie, a nie odziedziczony po domyślnym ustawieniu narzędzia. - Obowiązki autora, zanim poprosi o przegląd. Zrozumienie, którego umie bronić bez narzędzia, testy, które uruchomił, zmianę mieszczącą się w limicie wielkości. - Co recenzent może zamknąć bez czytania. Spisane, żeby polityka chroniła kolejkę przeglądów, a zamknięcie było regułą, nie osobistą decyzją. ### Gdzie zapisać deklarację: trailer, pole szablonu, etykieta Istnieją trzy mechanizmy i odpowiadają na różne pytania. W tym samym badaniu, wśród polityk wymagających ujawnienia, opis pull requesta jest miejscem wskazanym w 64,7% przypadków, a komunikat commita w 26,7%. Zespół, który chce zarówno przeglądu ze zrozumieniem, jak i audytu, potrzebuje dwóch z nich: pola szablonu i etykiety. Dwie konwencje się zderzają i polityka musi wybrać jedną. Agent chmurowy Copilota w GitHubie podpisuje swoje commity jako Copilot, z człowiekiem, który uruchomił zadanie, jako współautorem. Kubernetes zakazuje wpisywania AI jako współautora, bo narzędzie nie może podpisać umowy licencyjnej kontrybutora (CLA). Włączył też kontrolę CLA dla współautorów, żeby takie pull requesty były oznaczane jako niegotowe do scalenia. Repozytorium firmowe spotyka to samo pytanie w chwili, gdy umowa z klientem wymaga zidentyfikowanego autora, a odpowiedź musi być skonfigurowana w narzędziach, nie tylko zapisana w polityce. | Mechanizm | Kto to czyta | Do czego się nadaje | Jak jest sprawdzany | | --- | --- | --- | --- | | Trailer w commicie (Assisted-by: LLM w jądrze Linuksa; Generated-by: zalecany przez Apache Software Foundation) | Narzędzia i każdy, kto później czyta historię | Deklaracja w historii commita, czytelna dla maszyn; zachowanie jej po squashu wymaga konfiguracji scalania | Hook commit-msg i lint w CI z listą dozwolonych trailerów | | Pole w szablonie pull requesta: narzędzie, zakres, co zweryfikowano ręcznie | Recenzent, zanim otworzy diff | Wyjaśnienie własnymi słowami autora; miejsce, w którym widać zrozumienie | CI nie przechodzi, gdy pole jest puste albo nadal zawiera tekst szablonu | | Etykieta (ai-assisted) | Dashboardy, wyszukiwanie, próbka do audytu | Liczenie, filtrowanie, losowanie próbki do okresowego audytu | Bot ustawia etykietę na podstawie pola szablonu; nikt nie musi pamiętać | ### Co zdecydowały opublikowane projekty Wiersze poniżej są odczytane z własnych dokumentów projektów, nie z komentarzy o nich. Rozciągają się od pełnego zakazu do ujawnienia na żądanie i każdy jest wewnętrznie spójny: reguła pasuje do kontroli, którą projekt jest w stanie uruchomić. | Projekt | Reguła | Gdzie jest zapisana | | --- | --- | --- | | Jądro Linuksa | Dozwolone. Trailer Assisted-by: LLM; agenci nie mogą dodawać Signed-off-by; człowiek zgłaszający przegląda wszystko i poświadcza DCO | Documentation/process/coding-assistants.rst | | Kubernetes | Dozwolone z ujawnieniem. Bez AI jako współautora ani współpodpisu w commitach; kontrola CLA włączona dla współautorów, oznacza pull request jako niegotowy; recenzenci rozmawiają z ludźmi, a na komentarze z przeglądu nie odpowiada narzędzie | Blog kontrybutorów, czerwiec 2026 | | Apache Software Foundation | Dozwolone, gdy warunki narzędzia przyznają prawa do wyniku. Token Generated-by: w komunikacie commita; kontrybutor powiadamia fundację, jeśli później znajdzie kod na niezgodnej licencji | ASF Generative Tooling Guidance | | curl | Dozwolone dla kodu, który spełnia każde zwykłe wymaganie. Użycie AI w zgłoszeniach bezpieczeństwa musi być ujawnione; zmyślone zgłoszenia dostają natychmiastową blokadę | docs/CONTRIBUTE.md, sekcja On AI use in curl | | Ghostty | Dozwolone z pełnym ujawnieniem narzędzia i zakresu. Człowiek musi umieć wyjaśnić zmianę bez narzędzia; kontrybutorzy zgłaszający się po raz pierwszy otwierają prośbę o poręczenie własnymi słowami | AI_POLICY.md | | Gentoo | Zakazane od kwietnia 2024 z powodów prawnoautorskich, jakościowych i etycznych; egzekwowane przez zaufanie, nie przez wykrywanie | Polityka AI Rady | | QEMU | Odrzucane, gdy treść prawdopodobnie pochodzi z generatorów AI, z powodu DCO. AI do researchu, analizy statycznej i debugowania jest poza zakresem | docs/devel/code-provenance.rst | | Agent chmurowy GitHub Copilot | Commity podpisane przez Copilota z człowiekiem jako współautorem. Osoba, która zleciła pull request, nie może go zatwierdzić; workflow Actions czeka na zgodę kogoś z prawem zapisu | GitHub Docs, odpowiedzialne użycie agentów | ### Zrozumienie, testy, wielkość: co recenzent może zamknąć bez czytania Obowiązki autora decydują, czy czas przeglądu idzie na kod, czy na ustalanie, czym ten kod jest. Ghostty ujmuje to w jednym zdaniu: jeśli nie umiecie bez narzędzia wyjaśnić, co robią wasze zmiany i jak współdziałają z resztą systemu, nie wnoście wkładu. W firmie ta sama reguła ma praktyczną postać: pole szablonu prosi o powód zmiany słowami autora, a recenzent może zadać jedno pytanie, na które trzeba odpowiedzieć ze zrozumienia, z zamkniętym logiem sesji. Wielkość jest drugim obowiązkiem i wymaga ustalonej liczby. Praktyki inżynierskie Google podają 100 linii jako zwykle rozsądne i 1 000 jako zwykle za dużo na jedną zmianę, resztę zostawiając osądowi recenzenta. Zmiany pisane przez AI łatwo przekraczają tę górną granicę, bo dodawanie jest dla narzędzia tanie. Polityka ustala twardy limit dla pull requestów pisanych z AI i drogę wyjątku: notatkę projektową i plan podziału. Reguły zamykania bez czytania utrzymują ruch w kolejce bez zamieniania każdej decyzji w spór. curl podaje, że w 2025 roku poniżej 5% jego zgłoszeń bezpieczeństwa było zasadnych, zanim zakończył program bug bounty, a menedżer produktu GitHuba otworzył na przełomie stycznia i lutego 2026 publiczną dyskusję o pozwoleniu opiekunom na ograniczanie albo wyłączanie pull requestów. Zamknięcie na podstawie reguły jest lżejszą odpowiedzią na tę samą presję. Co recenzent może zamknąć bez otwierania diffu: - Brak powiązanego zgłoszenia albo przyjętej propozycji, w przypadku wkładu z zewnątrz - Wielkość ponad limit bez planu podziału - Puste pole deklaracji albo pole bez wskazanego zakresu zmiany i tego, co zweryfikowano ręcznie - Odpowiedzi na komentarze z przeglądu wklejone z wyniku narzędzia zamiast odpowiedzi autora - Wymagane testy, które nie wykonały się w CI, choć szablon je wymienia ### Szkielet polityki: reguła, kogo obowiązuje, jak jest sprawdzana Tabela to rezultat w skrócie. Każdy wiersz to jedna reguła, grupa, której dotyczy, oraz sposób sprawdzenia. Reguła bez sposobu sprawdzenia nie wchodzi do dokumentu. Wartości limitów, nazwiska właścicieli, harmonogram przeglądu i procedura zatwierdzania wyjątków to pola do uzupełnienia w waszej wersji. | Reguła | Kogo obowiązuje | Jak jest sprawdzana | | --- | --- | --- | | Osoba otwierająca pull request podpisuje pochodzenie i treść; narzędzia nie podpisują. W wariancie proponowanym nie są też wpisywane jako współautorzy | Wszystkich, łącznie z opiekunami i wykonawcami | Lint trailerów odrzuca trailery ze współautorem AI; kontrola CLA albo DCO obejmuje współautorów | | Pomoc AI jest deklarowana w polu szablonu: narzędzie, zakres, co zweryfikowano ręcznie | Wszystkich | CI nie przechodzi przy pustym albo niezmienionym polu; etykietę ustawia bot | | Autor umie wyjaśnić zmianę bez narzędzia | Wszystkich; recenzent może to sprawdzić jednym pytaniem | Punkt listy kontrolnej recenzenta; pytanie bez odpowiedzi blokuje scalenie | | Pull requesty pisane z AI mieszczą się w limicie wielkości albo mają plan podziału | Wszystkich | Bramka wielkości diffu w CI, z etykietą wyjątku i notatką projektową | | Testy uruchomione lokalnie są nazwane i uruchamiane także w CI | Wszystkich | CI jest źródłem prawdy; szablon wymienia polecenia | | Na komentarze z przeglądu odpowiada osoba | Kontrybutorów i opiekunów | Recenzent może zamknąć po jednej odpowiedzi wklejonej z narzędzia | | Tylko narzędzia z listy dopuszczonych, ze sprawdzonymi prawami do wyniku | Pracowników i wykonawców | Bot porównuje narzędzie z pola deklaracji z listą dopuszczonych narzędzi z praktyki Zasady korzystania z AI w firmie; u dostawców deklaracja w każdej dostawie jest sprawdzana przy odbiorze | | Recenzenci, którzy używają AI do przeglądu, podpisują przegląd jako własny | Recenzentów | To samo pole deklaracji przy przeglądzie | | Polityka jest przeglądana według harmonogramu i po każdym incydencie | Szefa inżynierii jako właściciela | Wpis w rejestrze ryzyk z datą przeglądu | ### Jak polityka łączy się z rejestrem ryzyk i zasadami korzystania z AI Polityka nie stoi sama. Jest jednym z artefaktów praktyki Zasady korzystania z AI w firmie, obok polityki użycia AI, listy dopuszczonych narzędzi i harmonogramu ewaluacji. Daje rejestrowi ryzyk konkretne wpisy: scalona niezweryfikowana zmiana napisana przez AI, wynik na niezgodnej licencji w bazie kodu, przepustowość przeglądu wyczerpana przez wolumen, atrybucja, której umowa nie akceptuje. Każdy wpis wskazuje kontrolę z szablonu jako swoje zabezpieczenie. Przestrzeganie polityki sprawdza okresowy audyt próbki. Losuje pull requesty z etykietą i sprawdza trzy rzeczy: czy deklaracja zgadzała się z diffem, czy wyjaśnienie autora się broniło i czy nazwane testy były testami uruchomionymi. Losuje też próbkę zmian bez etykiety, żeby wykryć pominięte deklaracje, z użyciem dostępnych śladów narzędzi. Raportuje udział tych, które nie przeszły. To ta sama metoda próbkowania co w praktyce Audyt kodu pisanego przez AI, zastosowana do procesu zamiast do kodu. ### Gdzie to się psuje i co z tym robimy **Trailer dodany przez edytor i polityka, która go zakazuje** W kwietniu 2026 VS Code zmienił domyślną wartość git.addAICoAuthor tak, że commity dostawały trailer Co-authored-by: Copilot; defekt przypisywał Copilotowi także podpowiedzi spoza Copilota, a w wersji 1.119 domyślne ustawienie wróciło do wyłączonego (microsoft/vscode, zgłoszenie #314311). Przez dwa wydania o atrybucji w historii commitów decydowało ustawienie edytora, nie autor. Zespół, którego polityka zakazuje współautorów AI, jak w Kubernetes, albo którego umowa z klientem wymaga zidentyfikowanego autora, znajduje to w historii po fakcie. Co z tym robimy: Wybieramy z wami jeden schemat atrybucji, zapisujemy go w polityce i konfigurujemy tam, gdzie powstają commity: ustawienia edytora, tożsamość commitów agenta, hook commit-msg odrzucający trailery spoza dozwolonej listy. Potem skanujemy historię pod kątem trailerów, które już weszły. Decyzję, co z nimi zrobić, zapisujemy. Co zostaje u was: schemat atrybucji w polityce, hook w repozytorium i lint w CI oraz raport ze skanu historii z listą dotkniętych commitów **Próg ujawnienia zapisany przymiotnikiem: istotne użycie** Polityki mówią, że istotne albo znaczące użycie AI musi być ujawnione. Badanie 1 000 najwyżej ocenianych repozytoriów (Hora i Robbes, lipiec 2026) wskazuje dokładnie te słowa jako powracającą niejednoznaczność. Bez obserwowalnego wyzwalacza dzieją się dwie rzeczy naraz: ostrożni inżynierowie deklarują wszystko, więc etykieta nie niesie informacji, a reszta nie deklaruje niczego, bo przyjęcie podpowiedzi nigdy nie wydawało się istotne. Co z tym robimy: Zastępujemy przymiotnik wyzwalaczami, które da się zaobserwować: deklaracja jest wymagana, gdy do zmiany wszedł fragment diffu przyjęty z narzędzia bez edycji albo gdy zmiana powstała w sesji agenta. W deklaracji autor podaje narzędzie z listy dopuszczonych, zakres i to, co zweryfikował ręcznie. Potem kalibrujemy próg na waszych niedawnych pull requestach i pokazujemy, jaki udział wymagałby deklaracji, żeby regułę poprawić przed ogłoszeniem, a nie po tym, jak zostanie zignorowana. Co zostaje u was: tabela decyzyjna dla deklaracji oraz raport z kalibracji na waszych niedawnych pull requestach **Autor podpisuje, agent odpowiada na przegląd** Recenzent pyta, dlaczego funkcja się zmieniła. Wiedza autora o zmianie to streszczenie agenta, więc odpowiedź jest wklejona od agenta, pytanie uzupełniające dostaje kolejne streszczenie, a przegląd staje się rozmową recenzenta z narzędziem, w której osoba przekazuje wiadomości. Kubernetes napisał swoją regułę na ten przypadek: recenzenci rozmawiają z ludźmi, a na komentarze z przeglądu nie odpowiada narzędzie. Pull requesty na tysiące linii napisanych przez AI to skrajna postać: nikt nie mógłby odpowiedzieć. Co z tym robimy: Umieszczamy pole wyjaśnienia w szablonie i prawo do jednego pytania w liście kontrolnej recenzenta, a pull requesty pisane z AI ograniczamy bramką wielkości, żeby na pytanie dało się odpowiedzieć. Gdy przegląd utyka na odpowiedzi wklejonej z narzędzia, lista kontrolna każe zamknąć, a polityka stoi za recenzentem. Co zostaje u was: szablon pull requesta z polem wyjaśnienia oraz lista kontrolna recenzenta z regułami zamykania **Polityka każe przeglądać wszystko, a wąskim gardłem jest kolejka** Polityka, która podnosi poprzeczkę autorom, nie zmienia niczego w liczbie nadchodzących pull requestów. curl podaje, że w 2025 roku poniżej 5% jego zgłoszeń bezpieczeństwa było zasadnych, po czym zakończył program bug bounty; GitHub otworzył dyskusję o pozwoleniu opiekunom na ograniczanie pull requestów. W firmie ta sama presja wygląda jak rosnące opóźnienie przeglądu, podczas gdy wszyscy trzymają się dokumentu, bo dokument nałożył wszystkie reguły na autora i żadnej na wejście. Co z tym robimy: Przenosimy reguły mechaniczne na wejście: powiązane zgłoszenie, wielkość, pole deklaracji, testy w CI, sprawdzane przez bota, zanim człowiek poświęci minutę. Potem mierzymy czas do pierwszego przeglądu i udział zamkniętych bez przeglądu, co miesiąc, żeby limit był strojony na liczbach, nie na frustracji. Co zostaje u was: kontrole wejściowe w CI i miesięczny raport z czasem do pierwszego przeglądu oraz udziałem zamkniętych na podstawie reguły **DCO podpisane dla wyniku, którego praw nikt nie sprawdził** Developer Certificate of Origin każe kontrybutorowi poświadczyć, że stworzył wkład albo ma prawo zgłosić go na danej licencji. Apache Software Foundation precyzuje, co to znaczy dla generowanego kodu: warunki narzędzia muszą przyznawać prawa do wyniku, a wynik nie może zawierać kodu osób trzecich na niezgodnej licencji. Podpisanie bez sprawdzenia jednego i drugiego zdarza się tam, gdzie lista narzędzi nigdy nie została spisana i nikt nie czytał warunków pod kątem tej klauzuli. Co z tym robimy: Dodajemy do listy dopuszczonych narzędzi kolumnę praw do wyniku, z klauzulą i datą jej odczytania. Uruchamiamy skanowanie licencji na plikach zmienionych w oznaczonych pull requestach, żeby rozpoznane licencje i podobieństwa wymagające sprawdzenia wyszły na jaw przed wydaniem. Polityka wskazuje, kto jest informowany, gdy tak się stanie, tak jak wytyczne ASF wymagają tego od swoich kontrybutorów. Co zostaje u was: lista dopuszczonych narzędzi z kolumną praw do wyniku oraz skan licencji plików zmienionych w pull requestach z etykietą ai-assisted ### Co dostajecie - Polityka wnoszenia kodu pisanego z AI: jeden dokument w układzie reguła / kogo obowiązuje / jak jest sprawdzana, obejmujący pracowników, wykonawców i kontrybutorów z zewnątrz - Szablon pull requesta z polem deklaracji i polem wyjaśnienia oraz konwencja trailerów w commitach - Konfiguracja repozytorium: hook commit-msg, kontrole CI dla trailerów, wielkości, deklaracji i testów, bot etykiet - Lista kontrolna recenzenta z regułami zamykania bez czytania - Raport z kalibracji progu ujawnienia na waszych niedawnych pull requestach - Wpisy w rejestrze ryzyk dla kodu pisanego z AI, każdy przypisany do kontroli z polityki - Lista dopuszczonych narzędzi rozszerzona o kolumnę praw do wyniku - Jednostronicowe streszczenie dla menedżerów i do przewodnika kontrybutora ### Jak pracujemy 1. **1. Odczyt stanu obecnego** (Dni 1-3): Skanujemy historię commitów pod kątem trailerów AI i współautorów, mierzymy wielkość pull requestów i opóźnienie przeglądu oraz czytamy, co już mówią wasz przewodnik kontrybutora i umowy. Wynikiem jest tabela z liczbami i cytatami z dokumentów. 2. **2. Projekt polityki i kalibracja progu** (Tydzień 1-2): Piszemy reguły ze sposobem sprawdzenia każdej z nich i kalibrujemy wyzwalacz ujawnienia na waszych niedawnych pull requestach; zespół bez takiej historii dostaje reguły ustalone na przykładowych zmianach, z przeglądem po pierwszym okresie stosowania. Potem przeglądamy projekt z inżynierią, działem prawnym oraz, gdy to ma znaczenie, z opiekunami. 3. **3. Narzędzia i wdrożenie** (Tydzień 2-3): Konfigurujemy szablon, hook, kontrole CI i bota etykiet, uruchamiamy je w trybie samego raportowania przez jeden cykl, a potem przełączamy na blokowanie. Recenzenci dostają listę kontrolną na krótkim szkoleniu. 4. **4. Przekazanie i pierwszy audyt** (Tydzień 3, potem po pierwszym cyklu): Przekazujemy politykę, konfigurację i wpisy do rejestru, a po pierwszym pełnym cyklu wracamy, losujemy próbkę oznaczonych pull requestów i raportujemy, jak reguły się sprawdziły. ### FAQ **Q: Czy trailer Assisted-by albo Co-authored-by czyni narzędzie autorem?** Nie. Odpowiedzialność za zgłoszony kod bierze osoba, która podpisuje; trailer zapisuje, że użyto narzędzia. Jądro Linuksa trzyma oba: trailer Assisted-by: LLM i Signed-off-by tylko dla ludzi. Kubernetes idzie w drugą stronę i zakazuje trailerów ze współautorem AI, bo narzędzie nie może podpisać CLA. Oba podejścia są spójne. Liczy się to, żeby wasza polityka wybrała jedno, a narzędzia były skonfigurowane zgodnie z nim. **Q: Czy nie lepiej po prostu zakazać kodu pisanego przez AI?** Gentoo i QEMU tak zrobiły, z powodów prawnoautorskich i jakościowych. Oba projekty mówią, że egzekwowanie opiera się na zaufaniu, nie na wykrywaniu. Dla firmy, która już licencjonuje asystentów kodowania, zakaz jest regułą, której nikt nie umie sprawdzić. Rekomendujemy formę warunkową: ujawnienie z obserwowalnym wyzwalaczem, test zrozumienia, limit wielkości i kontrole wejściowe, bo za każdą z nich stoi kontrola. **Q: Jak zastosować politykę do wykonawców i dostawców?** Te same reguły, przywołane z umowy: deklaracja w każdej dostawie, zidentyfikowany autor, który podpisuje, narzędzia z listy dopuszczonych i odbiór obejmujący audyt próbki oznaczonych zmian. Pochodzenie zadeklarowane przy dostawie kosztuje mniej niż pochodzenie odtwarzane w trakcie incydentu. **Q: Jaki limit wielkości powinny mieć pull requesty pisane z AI?** Nie ma liczby uniwersalnej. Opublikowana praktyka Google traktuje 100 linii jako zwykle rozsądne, a 1 000 jako zwykle za dużo, resztę oddając recenzentowi. Kalibrujemy limit na waszej przepustowości przeglądu i niedawnej historii, ustawiamy bramkę o jeden stopień poniżej poziomu, przy którym przeglądy zaczynały utykać. Zostawiamy drogę wyjątku z planem podziału. **Q: Czy recenzenci mogą używać AI do przeglądu?** Tak, na tej samej zasadzie co autorzy: recenzent podpisuje przegląd jako własny i umie obronić każdy komentarz bez narzędzia. Automatyczne komentarze z przeglądu są wsadem do przeglądu przez człowieka, a polityka mówi wprost, że zatwierdzenie przez bota nigdy nie liczy się jako wymagany przegląd. **Q: Jak to się ma do polityki użycia AI z praktyki Zasady korzystania z AI w firmie?** Polityka użycia mówi, których narzędzi wolno używać i z jakimi danymi. Polityka wnoszenia kodu mówi, jak ich wynik wchodzi do bazy kodu i kto za niego odpowiada. Dzielą listę dopuszczonych narzędzi i rejestr ryzyk, a piszemy je tak, żeby jedna odsyłała do drugiej zamiast ją powtarzać. **Q: Skąd wiadomo, że polityka jest przestrzegana?** Z próbki, według harmonogramu. Etykieta sprawia, że populacja jest policzalna; okresowy audyt losuje z niej pull requesty i sprawdza deklarację wobec diffu, wyjaśnienie wobec kodu i nazwane testy wobec CI. Druga, mniejsza próbka pochodzi ze zmian bez etykiety i służy wykryciu pominiętych deklaracji. Udział tych, które nie przeszły, jest liczbą śledzoną w rejestrze ryzyk. ### Powiązane - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zasady-korzystania-z-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai ### Źródła - Dokumentacja jądra Linuksa: AI Coding Assistants (tag Assisted-by, zasada Signed-off-by): https://docs.kernel.org/process/coding-assistants.html - Developer Certificate of Origin 1.1: https://developercertificate.org/ - Hora, Robbes, Zacchiroli: "We Permit the Use of AI, but [...]": The Landscape of AI Policies in Popular Open Source Projects (arXiv 2609.07542, wrzesień 2026): https://arxiv.org/html/2609.07542 - Hora, Robbes: AI Policy, Disclosure, and Human in the Loop: How Are Contribution Guidelines Adapting to GenAI? (arXiv 2605.16706, lipiec 2026): https://arxiv.org/html/2605.16706 - Blog kontrybutorów Kubernetes: Open source maintainership in the age of AI (26 czerwca 2026): https://www.kubernetes.dev/blog/2026/06/26/open-source-maintainership-in-the-age-of-ai/ - Apache Software Foundation: Generative Tooling Guidance: https://www.apache.org/legal/generative-tooling.html - curl: Contributing, sekcja On AI use in curl: https://curl.se/dev/contribute.html - Ghostty: AI Usage Policy: https://github.com/ghostty-org/ghostty/blob/main/AI_POLICY.md - Rada Gentoo: polityka AI (14 kwietnia 2024): https://wiki.gentoo.org/wiki/Project:Council/AI_policy - Dokumentacja QEMU: Code provenance: https://www.qemu.org/docs/master/devel/code-provenance.html - GitHub Docs: Responsible use of GitHub Copilot agents: https://docs.github.com/en/copilot/responsible-use/agents - GitHub Blog: GitHub Copilot, meet the new coding agent: https://github.blog/news-insights/product-news/github-copilot-meet-the-new-coding-agent/ - microsoft/vscode, zgłoszenie #314311: update on Co-authored-by: Copilot in commit messages: https://github.com/microsoft/vscode/issues/314311 - Google Engineering Practices: Small CLs: https://google.github.io/eng-practices/review/developer/small-cls.html - Daniel Stenberg: The end of the curl bug-bounty (26 stycznia 2026): https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/ - The Register: GitHub rozważa ograniczenie pull requestów przez opiekunów (3 lutego 2026): https://www.theregister.com/2026/02/03/github_kill_switch_pull_requests_ai/ --- ## Kalibracja sędziego LLM wobec ocen ludzi: protokół, który kończy się decyzją dla każdego kryterium **URL:** https://23minds.com/pl/przewodniki/kalibracja-sedziego-llm-wobec-ocen-ludzi > Kalibracja sędziego LLM wskazuje, które kryteria model oceniający (LLM-as-a-judge) może oceniać samodzielnie, a które wymagają udziału człowieka. Mierzy, jak często sędzia zgadza się z przeszkolonymi oceniającymi na tych samych wynikach, kryterium po kryterium, zanim jego oceny zaczną decydować o wydaniu. Sędzia jest drugim modelem z własnymi, udokumentowanymi skłonnościami, więc potrzebuje takich samych dowodów jak system, który ocenia. ### Podsumowanie 23Minds kalibruje sędziów LLM wobec ocen ludzi dla zespołów inżynierskich, które prowadzą automatyczną ewaluację i nie wiedzą, czy oceny sędziego zgadzają się z ocenami ich własnych recenzentów. Wynikiem jest spisana decyzja dla każdego kryterium: sędzia decyduje sam, sędzia sortuje i kieruje spory do człowieka albo kryterium zostaje przy ludziach. Klient zatrzymuje zbiór odniesienia oznaczony przez ludzi, raport zgodności z macierzą pomyłek dla każdego kryterium i procedurę ponownej kalibracji, uruchamianą przy każdej zmianie modelu sędziego, jego promptu albo zasad oceny, także na ruchu produkcyjnym po starcie. ### Dla kogo to jest - CTO i wiceprezesi ds. inżynierii, u których bramką wydania jest ocena sędziego LLM i których klient albo audytor zapytał, dlaczego tej ocenie można ufać - Zespoły, które wypróbowały kilka narzędzi do ewaluacji, wpięły sędziego w CI i nadal przeglądają wyniki ręcznie, bo nikt nie ufa liczbie - Inżynierowie platformowi i ML, którzy zmienili model sędziego albo jego prompt i zobaczyli, jak wskaźnik zaliczeń się przesuwa bez żadnej zmiany w produkcie - Właściciele produktów z agentami na produkcji, którzy potrzebują ewaluacji po starcie, a mają tylko benchmark sprzed startu ### Dlaczego sędzia w ogóle potrzebuje kalibracji Sędzia LLM to model językowy, któremu każe się ocenić wynik innego modelu według zasad oceny. Dziedziczy cechy, przez które modele językowe są trudne do oceny, a badania na ten temat są konkretne. Zheng i współautorzy (2023), autorzy MT-Bench i Chatbot Arena, wymieniają jako usterki sędziego skłonność do pozycji, do długości, do własnych odpowiedzi oraz ograniczoną zdolność rozumowania. Wang i współautorzy (2023) odwrócili ranking dwóch odpowiedzi kandydujących samą zamianą ich kolejności w prompcie: Vicuna-13B wygrała z ChatGPT w 66 z 80 zapytań przy ChatGPT jako oceniającym, wyłącznie przez zmianę kolejności. Saito i współautorzy (2023) zmierzyli, że GPT-4 woli dłuższe odpowiedzi bardziej niż ludzie. Panickssery, Bowman i Feng (2024) ustalili, że oceniające modele rozpoznają własne teksty i faworyzują je proporcjonalnie do tego, jak dobrze je rozpoznają. Ye i współautorzy (2024) skatalogowali dwanaście skłonności sędziów LLM, między innymi wobec autorytetu, większości, nastroju, przeoczenia błędu logicznego i informacji o dopracowaniu, gdzie sama wiadomość, że odpowiedź została poprawiona, zmienia ocenę. Nic z tego nie czyni sędziego bezużytecznym. Zheng i współautorzy podali też, że mocny sędzia osiągnął ponad 80% zgodności z preferencjami ludzi, czyli poziom, jaki ludzie osiągali między sobą. Rzecz w tym, że ten poziom jest mierzony, dla każdego zadania, a sędzia wrzucony do potoku CI bez takiego pomiaru to drugi system, którego błędów nikt nie obejrzał. Praktycy na forach programistów opisują dokładnie ten stan: wyniki obejrzane na oko i uznane za gotowe, sędzia z tej samej rodziny oceniający własne odpowiedzi i żadnej ewaluacji, gdy agent jest już na produkcji. Kalibracja pokazuje, jak często i w jakich przypadkach oceny modelu różnią się od ocen ludzi. ### Najpierw ludzie: zbiór odniesienia i to, jak bardzo ludzie zgadzają się między sobą Sędzia może być tylko tak dobry jak etykiety, z którymi jest porównywany, więc protokół zaczyna od ludzi i od zasad oceny (rubryki). Każde kryterium dostaje spisaną definicję, skalę i przykłady dla każdego punktu skali. Próbka prawdziwych wyników, pobrana z ruchu produkcyjnego albo ze zbioru odłożonego, jest oznaczana niezależnie przez co najmniej dwóch oceniających, którzy nie widzą swoich ocen nawzajem. Rozbieżności idą do rozstrzygnięcia, a rozstrzygnięta etykieta staje się odniesieniem. Przy każdej rozbieżności najpierw rozpoznaje się jej przyczynę: brak kontekstu, przygotowanie oceniających, rzeczywista niejednoznaczność albo definicja kryterium. Każda poprawka zasad oceny dokonana w trakcie rozstrzygania jest zapisywana, bo zasady, których ludzie nie umieli stosować spójnie, są pierwszym artefaktem do naprawy, zanim sędzia w ogóle zostanie uruchomiony. Zgodność między ludźmi jest mierzona dla każdego kryterium, statystyką skorygowaną o przypadek obok surowego odsetka zgodności: kappa Cohena dla dwóch oceniających, kappa ważona dla skal porządkowych, alfa Krippendorffa dla większej liczby oceniających albo brakujących etykiet; korelację Spearmana podaje się osobno, jako miarę zależności, nie zgodności. McHugh (2012) zaleca podawanie zarówno odsetka zgodności, jak i kappy i odczytuje kappę poniżej 0,60 jako niewystarczającą, podczas gdy starsza skala Landisa i Kocha nazywa 0,41-0,60 zgodnością umiarkowaną; protokół nie ustala progu uniwersalnego, bo właściwy próg zależy od tego, ile w waszym produkcie kosztuje błędne zaliczenie. Wartość zgodności między ludźmi jest natomiast punktem odniesienia: zgodność sędziego z rozstrzygniętymi etykietami czyta się wobec niej, nie w oderwaniu. Kryterium, na którym ludzie się nie zgadzają, nie nadaje się do automatyzacji, cokolwiek raportuje sędzia. ### Pomiar sędziego: protokół kalibracji Gdy zbiór odniesienia jest gotowy, sędzia ocenia tę samą próbkę, a każda z jego znanych skłonności dostaje własny test. Tabela to protokół w takiej postaci, w jakiej jest wykonywany; odnośniki do źródeł na końcu strony niosą uzasadnienie każdego wiersza. | Krok | Co się robi | Co to wychwytuje | Co się zapisuje | | --- | --- | --- | --- | | Rozdzielenie rodzin | Sędzia pochodzi z innej rodziny modeli niż testowany system, zgodnie z zaleceniem z dokumentacji Anthropic o ewaluacji | Ogranicza skłonność do własnych odpowiedzi; wykrywa ją porównanie ocen obu sędziów z ocenami ludzi | Model sędziego, identyfikator wersji, skrót promptu | | Zgodność dla każdego kryterium | Etykieta sędziego wobec rozstrzygniętej etykiety ludzi, tą samą statystyką, której użyto między ludźmi | Kryteria, na których sędzia się rozjeżdża, choć wynik łączny wygląda dobrze | Kappa albo alfa dla każdego kryterium, obok wartości między ludźmi | | Macierz pomyłek dla każdego kryterium | Dla każdego punktu skali: jak sędzia ocenił to, co ludzie tam umieścili | Kierunek błędu; koszt błędnego zaliczenia i błędnego odrzucenia ustalany osobno dla każdego kryterium | Jedna macierz dla każdego kryterium, z nazwanym kosztem każdej komórki | | Zamiana kolejności | Każde porównanie parami uruchomione w obu kolejnościach | Skłonność do pozycji, według kalibracji z pracy Wanga i współautorów (2023) | Udział par, w których werdykt zmienia się z kolejnością | | Kontrola długości | Korelacja między oceną sędziego a długością wyniku, porównana z tą samą korelacją dla etykiet ludzi; sygnał sprawdzany porównaniem odpowiedzi o podobnej poprawności | Skłonność do długości | Dwa współczynniki korelacji dla każdego kryterium i wynik porównania | | Stabilność i powtarzalność | Zmiana instrukcji (z krokiem rozumowania i bez niego) badana osobno; powtarzalność przez wielokrotne uruchomienia w identycznych warunkach | Wrażliwość na łańcuch rozumowania; niedeterminizm | Zgodność sędziego z samym sobą między przebiegami, osobno dla obu testów | ### Decyzja dla każdego kryterium Wynikiem kalibracji jest decyzja, spisana dla każdego kryterium, co sędziemu wolno. Trzy wyniki pokrywają praktykę. Sędzia decyduje sam tam, gdzie jego zgodność z rozstrzygniętymi etykietami dorównuje poziomowi, jaki ludzie osiągnęli między sobą, przedział ufności tej zgodności nie schodzi poniżej ustalonego z góry progu, a macierz pomyłek pokazuje, że jego błędy padają po stronie, której koszt uzgodniono jako akceptowalny. Sędzia sortuje tam, gdzie jego zgodność jest niższa, ale błędne zaliczenia są rzadkie: ocenia wszystko, a każde odrzucenie plus losowa próbka zaliczeń idą do człowieka. Kryterium zostaje przy ludziach tam, gdzie sami ludzie się nie zgadzali, a praca wraca do zasad oceny, oraz tam, gdzie ludzie oceniają spójnie, a sędzia często popełnia kosztowne błędy, do czasu poprawy albo wymiany sędziego. Ta decyzja jest tym, co wpina się w CI. Jeden wskaźnik zaliczeń dla wszystkich kryteriów zastępują bramki dla każdego kryterium z różnymi właścicielami, a zbiór kalibracyjny leży obok zestawu testów, wersjonowany razem z zasadami oceny. Wydanie, które zmienia prompt sędziego, uruchamia kalibrację ponownie, zanim zmieni bramkę. - Decyduje sam: zgodność na poziomie zgodności między ludźmi, przy ustalonych progach błędów i kosztach pomyłek; sędzia blokuje scalenie na tym kryterium. - Sortuje i kieruje: zgodność poniżej poziomu ludzi, błędne zaliczenia rzadkie; sędzia sortuje, człowiek decyduje o oznaczonej części. - Zostaje przy ludziach: ludzie nie zgadzają się między sobą albo sędzia często popełnia kosztowne błędy; zasady oceny są przepisywane, a kryterium oznaczane ponownie, zanim sędzia zostanie wypróbowany jeszcze raz. - Każda decyzja nazywa kryterium, statystykę, wartość, zgodność między ludźmi i osobę, która jest właścicielem bramki. ### Ponowna kalibracja i ewaluacja po starcie Skalibrowany sędzia jest skalibrowany dla jednej wersji modelu, jednego promptu i jednych zasad oceny. Chen, Zaharia i Zou (2023) zmierzyli ten sam endpoint GPT-4 w marcu i czerwcu 2023 i stwierdzili, że jego skuteczność w rozpoznawaniu liczb pierwszych spadła z 84% do 51%, a razem z nią pogorszyło się wykonywanie instrukcji. Sędzia serwowany przez API może w ten sam sposób zmienić działanie bez żadnej zmiany po waszej stronie, dlatego model sędziego jest przypięty do identyfikatora wersji, a ponowna kalibracja uruchamia się na cztery sygnały: zmiana modelu albo wersji sędziego, zmiana promptu sędziego, zmiana zasad oceny oraz zmiana tego, co produkt wysyła, na przykład nowy język albo typ zadania. Kalibracja przed startem to połowa pracy. Po starcie sędzia ocenia próbkę śladów produkcyjnych, a w stałym rytmie człowiek oznacza ponownie losowy wycinek tego, co sędzia ocenił. Zgodność staje się szeregiem czasowym dla każdego kryterium, a spadek jest sygnałem, żeby przyjrzeć się sędziemu albo produktowi, zanim zrobią to klienci. Dokumentacja graderów OpenAI opisuje tę samą kontrolę od strony treningu: model, który nauczył się zadowalać grader, dostaje dobre oceny od gradera i słabe od ekspertów, a jedynym sposobem, żeby to zobaczyć, jest dalsze pytanie ludzi. ### Gdzie to się psuje i co z tym robimy **Sędzia pochodzi z rodziny, która wyprodukowała odpowiedzi** Ten sam model albo jego krewny od tego samego dostawcy generuje wynik i go ocenia. Panickssery, Bowman i Feng (2024) pokazali, że oceniające modele rozpoznają własny tekst i faworyzują go proporcjonalnie do tego, jak dobrze go rozpoznają, więc wskaźnik zaliczeń niesie premię za styl, której żaden człowiek nie dał. Zespół czyta wysoką ocenę jako jakość, bo nic w potoku nie raportuje, która rodzina co oceniła. Co z tym robimy: Uruchamiamy próbkę kalibracyjną ponownie z sędzią z innej rodziny i z ukrytą tożsamością kandydata, a potem porównujemy zgodność z rozstrzygniętymi etykietami dla obu sędziów. Tam, gdzie sędzia z tej samej rodziny ocenia własne wyniki wyżej niż ludzie, sędzia jest wymieniany albo kryterium przechodzi do sortowania. Model i wersję sędziego zapisujemy obok każdej oceny, żeby rodzina była widoczna w każdym raporcie. Co zostaje u was: porównanie zgodności dla dwóch rodzin sędziów na tej samej próbce oraz specyfikacja sędziego z modelem, wersją i skrótem promptu **Kolejność i długość decydują o werdykcie** Porównania parami są wysyłane w stałej kolejności, a sędzia faworyzuje pierwsze albo drugie miejsce; oceny pojedynczych odpowiedzi rosną z długością wyniku niezależnie od poprawności. Wang i współautorzy (2023) odwrócili wynik benchmarku samą zmianą kolejności, a Saito i współautorzy (2023) zmierzyli, że GPT-4 woli dłuższe odpowiedzi bardziej niż ludzie. Zmiana promptu, która czyni produkt bardziej rozwlekłym, czyta się wtedy jako poprawa jakości. Co z tym robimy: Każdą ocenę parami uruchamiamy w obu kolejnościach i liczymy udział par, w których werdykt się zmienia, a dla sędziego i dla etykiet ludzi na tej samej próbce liczymy korelację między oceną a długością. Pary, które się odwracają, są wyłączone z bramki do czasu poprawienia promptu, a korelacja z długością, której ludzie nie podzielają, przenosi kryterium do sortowania. Co zostaje u was: wskaźnik spójności wobec kolejności i korelacja oceny z długością dla każdego kryterium, sędzia obok ludzi **Zgodność sędziego mierzona wobec etykiet jednej osoby** Jeden inżynier oznacza zbiór odniesienia sam, sędzia zgadza się z tymi etykietami przez większość czasu, a liczba jest przedstawiana jako kalibracja. Nikt nie wie, czy druga osoba oznaczyłaby tak samo, więc wynik nie ma punktu odniesienia, wobec którego można go odczytać. Gdy sędzia później nie zgadza się z recenzentem na produkcji, nie da się powiedzieć, które z nich się myli. Co z tym robimy: Każdy element jest oznaczany niezależnie przez co najmniej dwóch oceniających, rozbieżności rozstrzygamy, a statystykę zgodności między ludźmi raportujemy dla każdego kryterium przed jakąkolwiek liczbą o sędzim. Kryteria, na których ludzie się nie zgadzają, wracają do zasad oceny razem z rozbieżnościami i rozpoznaną przyczyną każdej z nich, bo sędziego nie da się skalibrować wobec etykiet, co do których ludzie nie byli zgodni. Co zostaje u was: zbiór odniesienia z dwiema niezależnymi etykietami i etykietą rozstrzygniętą dla każdego elementu oraz zgodność między ludźmi dla każdego kryterium **Jedna ocena łączna ukrywa kryterium, które zawodzi** Sędzia zwraca jedną liczbę na wynik albo oceny dla kryteriów są uśredniane do wskaźnika zaliczeń. Zgodność na wyniku łącznym wygląda akceptowalnie, podczas gdy na jednym kryterium, zwykle tym, które kosztuje najwięcej, gdy jest błędne, sędzia zalicza to, co ludzie odrzucają. Średnia to ukrywa, bo pozostałe kryteria są łatwe i liczne. Co z tym robimy: Liczymy zgodność i macierz pomyłek dla każdego kryterium i nazywamy koszt każdej komórki: błędne zaliczenie na kryterium bezpieczeństwa albo poprawności waży inaczej niż błędne odrzucenie na kryterium tonu. Każde kryterium dostaje własną decyzję i własnego właściciela bramki, a ocena łączna znika z potoku. Co zostaje u was: macierz pomyłek dla każdego kryterium z kosztem każdej komórki oraz rejestr decyzji z jednym wierszem na kryterium **Model sędziego się zmienił, a kalibracja nie** Sędzia jest wywoływany przez alias wskazujący bieżącą wersję u dostawcy albo jego prompt jest edytowany przy okazji niezwiązanej zmiany. Chen, Zaharia i Zou (2023) udokumentowali, jak zachowanie tego samego endpointu przesunęło się znacząco w ciągu trzech miesięcy. Bramka dalej zalicza albo zaczyna odrzucać, a zespół debuguje produkt z powodu zmiany, która zaszła w sędzim. Co z tym robimy: Przypinamy sędziego do identyfikatora wersji, liczymy skrót promptu sędziego i dodajemy kontrolę, która blokuje zmianę konfiguracji sędziego bez zapisanego wyniku ponownej kalibracji. Ponowna kalibracja używa tego samego zbioru roboczego, więc zgodność przed zmianą i po niej jest bezpośrednio porównywalna, a końcowe sprawdzenie idzie na osobnym zbiorze kontrolnym, żeby prompt nie został dopasowany do znanych przykładów. Rejestr decyzji dostaje datę i nowe wartości. Co zostaje u was: dziennik ponownych kalibracji ze zgodnością dla każdego kryterium przed każdą zmianą sędziego albo zasad oceny i po niej oraz przypięta wersja sędziego ### Co dostajecie - Zbiór kalibracyjny: próbka wyników z dwiema niezależnymi etykietami ludzi i etykietą rozstrzygniętą dla każdego elementu i kryterium, podzielony na zbiór roboczy i zbiór kontrolny, wersjonowany razem z zasadami oceny - Zasady oceny z definicjami, skalami i przykładami dla każdego punktu skali, łącznie z poprawkami wprowadzonymi podczas rozstrzygania i ich uzasadnieniem - Raport zgodności dla każdego kryterium: statystyki między ludźmi i sędzia-ludzie, macierze pomyłek z wycenionymi komórkami, wyniki zamiany kolejności i kontroli długości - Rejestr decyzji: dla każdego kryterium decyduje sam, sortuje i kieruje albo zostaje przy ludziach, z wynikami uzasadniającymi decyzję i właścicielem bramki - Specyfikacja sędziego: rodzina modelu, przypięta wersja, skrót promptu, losowanie kolejności i temperatura, z kontrolą w CI, która blokuje zmianę konfiguracji sędziego bez zapisanego wyniku ponownej kalibracji - Procedura ponownej kalibracji z czterema sygnałami oraz plan okresowego porównywania ocen modelu z ocenami ludzi na próbce z produkcji, z zasadami odświeżania zbioru kontrolnego ### Jak pracujemy 1. **1. Rubryka i zbiór odniesienia** (Tydzień 1-2): Ustalamy kryteria oceny albo porządkujemy te, których już używacie, piszemy albo zaostrzamy definicję, skalę i przykłady dla każdego z nich i pobieramy próbkę ze śladów produkcyjnych albo z waszego zbioru odłożonego. Próbka jest warstwowana tak, żeby przypadki rzadkie, ale kosztowne były obecne w liczbie, którą da się zmierzyć; ich wyniki raportujemy osobno od oszacowań dla rzeczywistego ruchu, z ważeniem opisanym w raporcie. 2. **2. Oznaczanie przez ludzi i rozstrzyganie** (Tydzień 2-3): Dwóch oceniających z waszego zespołu albo z naszego, jeśli wolicie parę z zewnątrz, oznacza każdy element niezależnie. Rozbieżności rozstrzygamy z wami, zapisujemy każdą zmianę zasad oceny i raportujemy zgodność między ludźmi dla każdego kryterium. Kryteria, które tu nie przechodzą, wracają do kroku 1, zanim ktokolwiek dotknie sędziego. 3. **3. Pomiar sędziego** (Tydzień 3-4): Uruchamiamy waszego obecnego sędziego (albo pierwszego, jeśli go jeszcze nie macie) i co najmniej jednego sędziego z innej rodziny na zbiorze odniesienia, w obu kolejnościach dla elementów porównywanych parami, z krokiem rozumowania i bez niego oraz wielokrotnie w identycznych warunkach. Liczymy zgodność, macierze pomyłek, spójność wobec kolejności i korelację z długością dla każdego kryterium. 4. **4. Decyzja i wpięcie w CI** (Tydzień 4-5): Piszemy z wami rejestr decyzji, zastępujemy bramkę łączną bramkami dla każdego kryterium z właścicielami, przypinamy wersję i prompt sędziego i dodajemy kontrolę, która blokuje zmianę sędziego bez zapisanej ponownej kalibracji. 5. **5. Przekazanie i pierwszy cykl produkcyjny** (Tydzień 5-6, zależnie od wielkości zbioru i dostępności oceniających): Przekazujemy zbiór kalibracyjny, raport i procedurę ponownej kalibracji, prowadzimy z waszym zespołem pierwsze ponowne oznaczanie na produkcji i zostawiamy szereg czasowy zgodności w waszych narzędziach monitorowania, żeby następny spadek był widoczny bez nas. ### FAQ **Q: Nasz sędzia zgadza się z naszymi etykietami w około 85% przypadków. Czy to dobrze?** To zależy od dwóch rzeczy, których ta liczba nie pokazuje: jak często wasi ludzie zgadzają się między sobą na tych samych elementach i gdzie padają rozbieżności. Jeśli ludzie też zgadzają się w 85%, sędzia jest na poziomie ludzi. Jeśli ludzie zgadzają się w 95%, a pomyłki sędziego to błędne zaliczenia na kryterium, które ma największe znaczenie, 85% to co najwyżej sędzia sortujący. Zgodność między ludźmi i macierz pomyłek raportujemy obok tej liczby, żeby dało się ją odczytać. **Q: Której statystyki zgodności użyć?** Odsetka zgodności razem ze statystyką skorygowaną o przypadek, podawanych łącznie, tak jak zaleca McHugh (2012). Kappa Cohena dla dwóch oceniających na etykietach kategorialnych, kappa ważona dla skal porządkowych, alfa Krippendorffa przy większej liczbie oceniających albo brakujących etykietach; korelacja Spearmana osobno, jako miara zależności. Wybór ma mniejsze znaczenie niż raportowanie dla każdego kryterium i użycie tej samej statystyki dla ludzi i dla sędziego, żeby obie wartości dało się porównać. **Q: Czy sędzią może być ten sam model, którego używamy w produkcie, z innym promptem?** Opublikowane badania mówią, że właśnie tam żyje faworyzowanie własnych odpowiedzi: Panickssery, Bowman i Feng (2024) ustalili, że oceniające modele faworyzują własne teksty proporcjonalnie do tego, jak dobrze je rozpoznają, a wytyczne Anthropic o ewaluacji każą oceniać innym modelem niż ten, który wyprodukował wynik. Mierzymy to zamiast zakładać: jeśli sędzia z innej rodziny zgadza się z waszymi ludźmi częściej na tej samej próbce, odpowiedź dla waszego produktu brzmi nie. **Q: Ile oznaczonych elementów potrzebuje zbiór odniesienia?** Tyle dla każdego kryterium i każdego punktu skali, żeby macierz pomyłek miała komórki, które da się odczytać, z nadpróbkowaniem przypadków rzadkich i kosztownych. Nie ma liczby uniwersalnej, a każda liczba podana bez waszych kryteriów i waszych kosztów błędu jest zgadywaniem. Wielkość próbki ustala się w kroku 1 na podstawie pewności, jakiej potrzebujecie do decyzji, a zbiór rośnie z każdym ponownym oznaczaniem na produkcji. **Q: Co się dzieje, gdy dostawca aktualizuje model sędziego?** Przypięty identyfikator wersji utrzymuje starego sędziego tak długo, jak dostawca tę wersję udostępnia; procedura obejmuje też wycofanie wersji przez dostawcę. Przejście to przebieg ponownej kalibracji na tym samym zbiorze odniesienia, krótki, bo zbiór i skrypty już istnieją. Rejestr decyzji dostaje nowe wartości; kryterium, które spada poniżej poziomu ludzi, przechodzi z decydowania do sortowania do czasu poprawienia promptu albo zasad oceny. **Q: Jesteśmy już na produkcji bez skalibrowanego sędziego. Od czego zacząć?** Od śladów produkcyjnych, które są najlepszym zbiorem odniesienia, jaki dostaniecie. Pobieramy próbkę z żywego ruchu, oznaczamy ją z waszymi recenzentami i na tym kalibrujemy sędziego. Pierwszy cykl ponownego oznaczania to kalibracja sprzed startu, której nie mieliście. Od niego zaczyna się szereg czasowy. **Q: Czy kalibracja całkiem zastępuje przegląd przez ludzi?** Zastępuje go na kryteriach, na których sędzia na to zasłużył, a utrzymuje tam, gdzie nie. Które jest które, mówi na piśmie. Kryteria sortowane nadal kierują część elementów do człowieka, a każde kryterium zachowuje okresowe ponowne oznaczanie. Sędzia bez ludzi za sobą dryfuje i nikt tego nie zauważa, dopóki nie zauważy klient. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/ewaluacja-jakosci-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability ### Źródła - Zheng i in. (2023), Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena: uprzedzenie do pozycji, długości i własnych odpowiedzi; ponad 80% zgodności z ludźmi, tyle co między ludźmi: https://arxiv.org/abs/2306.05685 - Wang i in. (2023), Large Language Models are not Fair Evaluators: uprzedzenie do pozycji, Vicuna-13B wygrywa z ChatGPT w 66 z 80 zapytań po zmianie kolejności, kalibracja przez zamianę pozycji: https://arxiv.org/abs/2305.17926 - Panickssery, Bowman i Feng (2024), LLM Evaluators Recognize and Favor Their Own Generations: rozpoznawanie własnych tekstów koreluje z ich faworyzowaniem: https://arxiv.org/abs/2404.13076 - Saito i in. (2023), Verbosity Bias in Preference Labeling by Large Language Models: GPT-4 woli dłuższe odpowiedzi bardziej niż ludzie: https://arxiv.org/abs/2310.10076 - Ye i in. (2024), Justice or Prejudice? Quantifying Biases in LLM-as-a-Judge: dwanaście uprzedzeń, w tym wobec autorytetu, większości i tonu, przeoczanie błędów rozumowania i wrażliwość na informację o poprawianiu: https://arxiv.org/abs/2410.02736 - Chen, Zaharia i Zou (2023), How is ChatGPT's behavior changing over time?: ten sam endpoint, marzec i czerwiec 2023, rozpoznawanie liczb pierwszych z 84% do 51%: https://arxiv.org/abs/2307.09009 - McHugh (2012), Interrater reliability: the kappa statistic, Biochemia Medica: odsetek zgodności i kappa podawane razem; skale interpretacji: https://pmc.ncbi.nlm.nih.gov/articles/PMC3900052/ - Anthropic, Create strong empirical evaluations: ocena przez model i zalecenie, żeby oceniać innym modelem niż testowany: https://platform.claude.com/docs/en/test-and-evaluate/develop-tests - OpenAI, Graders: gradery modelowe i wykrywanie grader hacking przez porównanie z ocenami ekspertów: https://developers.openai.com/api/docs/guides/graders --- ## Katalog incydentów bezpieczeństwa w kodzie pisanym z AI: co zawiodło i jaka kontrola by to wykryła **URL:** https://23minds.com/pl/przewodniki/katalog-incydentow-bezpieczenstwa-kodu-ai > Katalog incydentów to datowana lista przypadków, w których kod napisany z asystentem AI albo warstwa aplikacji wokół modelu językowego zawiodły w sposób publicznie udokumentowany: rekordem CVE, biuletynem dostawcy, oficjalnym raportem po incydencie albo recenzowanym pomiarem. Ta strona prowadzi taki katalog, uporządkowany według mechanizmu, z kontrolą dopasowaną do każdego z tych mechanizmów. ### Podsumowanie 23Minds prowadzi katalog publicznie udokumentowanych incydentów bezpieczeństwa w kodzie pisanym z AI i w warstwie aplikacji wokół LLM, dla szefów inżynierii, którzy chcą wiedzieć, co naprawdę poszło nie tak gdzie indziej, zanim zdecydują, co sprawdzić u siebie. Każdy wpis ma datę, źródło pierwotne (rekord CVE, biuletyn dostawcy, oficjalny raport po incydencie albo opublikowane badanie) i jeden nazwany mechanizm: treść czytana przez agenta potraktowana jak polecenie, wygenerowany domyślny backend wdrożony bez zmian, zmyślona nazwa pakietu zainstalowana z rejestru, destrukcyjne polecenie uruchomione z wyłączonym potwierdzeniem, wynik modelu przekazany do SQL albo do wykonania kodu, narzędzie MCP albo rozszerzenie z dostępem szerszym niż zadanie. Katalog jest punktem wyjścia do przeglądu bezpieczeństwa kodu pisanego przez AI: każda klasa mechanizmu ma listę kontrolną, wynik testu dla danej bazy kodu z zakresem sprawdzenia i ponowny test po poprawce. Incydenty objęte NDA nie wchodzą do katalogu; tylko to, co da się sprawdzić u źródła. ### Dla kogo to jest - CTO i wiceprezesi ds. inżynierii, których zespoły wdrażają kod z Copilota, Cursora, Claude Code albo Gemini CLI i których zarząd albo klient zapytał, co może pójść nie tak - Szefowie bezpieczeństwa i zespołów platformowych, którzy dodali agenta w aplikacji, serwer MCP albo automatyzację wsparcia na LLM i potrzebują konkretnej listy zagrożeń zamiast ogólnej - Software house'y, które dostarczają klientom kod pisany z AI, a klienci proszą teraz o dowód niezależnego sprawdzenia bezpieczeństwa - Inżynierowie, którzy czytają biuletyny dostawców jeden po drugim i chcą mieć je w jednym miejscu, posortowane według mechanizmu ### Co jest wpisem, a co nim nie jest O cudzych incydentach z agentami kodującymi zespoły słyszą rzadko: NDA i wstyd trzymają je poza publicznym obiegiem, więc zespoły polegają na deklaracjach dostawców. Katalog poniżej idzie odwrotną drogą i wymienia tylko to, co da się sprawdzić u źródła: rekord CVE, biuletyn bezpieczeństwa dostawcy, publiczne oświadczenie kierownictwa dostawcy albo recenzowany pomiar z opublikowaną metodą. Relacja prasowa wchodzi tylko wtedy, gdy przytacza publiczne oświadczenie dostawcy, a wiersz to oznacza. Wpisy są trzech rodzajów: incydenty z potwierdzoną szkodą, podatności z rekordem CVE albo biuletynem oraz demonstracje badaczy; kolumna Skutek mówi, o który rodzaj chodzi. Wątki praktyków, którzy liczą incydenty z codziennej pracy, są przydatne jako format, ale wątek nie jest źródłem i żaden nie jest tu cytowany. Trzy granice trzymają listę w ryzach. Obejmuje kod i warstwę aplikacji: co napisał asystent, co aplikacja wysyła do modelu i czemu ufa w odpowiedzi, co agent ma prawo wywołać. Nie obejmuje infrastruktury, konfiguracji chmury, bezpieczeństwa sieci, testów penetracyjnych ani SOC; to osobne dyscypliny z własnymi katalogami. Nie traktuje też modelu jak winowajcy. Każdy wiersz to narzędzie użyte bez kontroli, którą postawiłby przed nim proces. Właśnie dlatego każdy wiersz ma dopisaną kontrolę. ### Katalog Posortowany według daty publikacji źródła (rekordu CVE, biuletynu, raportu albo badania). Kolumna klasy używa sześciu klas mechanizmów zdefiniowanych w następnej sekcji. Odnośniki do źródeł są na końcu strony. Oceny ważności to wartości CVSS z rekordów CVE tam, gdzie rekord istnieje; przy ForcedLeak wartość pochodzi z raportu Noma Security. | Data | System i źródło | Co zawiodło | Skutek | Klasa | Kontrola dla tego mechanizmu | | --- | --- | --- | --- | --- | --- | | 2023-07 | LangChain SQLDatabaseChain, CVE-2023-36189 | SQL wygenerowany przez model wykonany na bazie bez granicy między pytaniem a zapytaniem | Zdalny atakujący uzyskuje wrażliwe informacje przez łańcuch | E | Rola bazodanowa ograniczona do tabel potrzebnych w zadaniu, lista dozwolonych instrukcji, przegląd zapytania przed wykonaniem, test odczytu bez wymaganych uprawnień | | 2024-03 | huggingface-cli na PyPI, eksperyment Lasso Security | Nazwa pakietu wielokrotnie zmyślana przez asystentów została zarejestrowana przez badaczy; publiczne repozytorium badawcze Alibaby miało ją w instrukcji instalacji | Pusty pakiet zainstalowany przez prawdziwe projekty, które poszły za instrukcją napisaną przez asystenta | C | Sprawdzenie rejestru przy każdej nowej zależności: wiek, wydawca, historia pobrań, oraz diff pliku blokady w przeglądzie | | 2024-05 | Vanna.AI text-to-SQL, CVE-2024-5565, CVSS 8,1 | Niezaufane wejście w ask() dociera do promptu, który pisze kod wizualizacji Plotly, a ten kod jest wykonywany | Zdalne wykonanie kodu; obejście polega na wyłączeniu wizualizacji dla niezaufanego wejścia | E | Bez wykonywania kodu napisanego przez model ze ścieżek dostępnych użytkownikom; renderowanie w piaskownicy; wejście oznaczone jako niezaufane na całej drodze | | 2025-05 | GitLab Duo, ujawnienie Legit Security | Ukryty tekst w merge requestach, zgłoszeniach, commitach i kodzie (biały KaTeX, kodowanie base16) czytany przez Duo jak polecenia | Prywatny kod źródłowy wyprowadzony przez wstrzyknięty znacznik obrazu; niebezpieczne adresy URL pokazane jako bezpieczne | A | Lista dozwolonych adresów wychodzących dla renderowanych odpowiedzi asystenta; usuwanie aktywnego HTML z odpowiedzi; zestaw testów wstrzyknięć w CI | | 2025-05 | Serwer GitHub MCP, Invariant Labs | Publiczne zgłoszenie wydaje polecenia agentowi, który ma token także do prywatnych repozytoriów | Dane z prywatnego repozytorium wpisane do publicznego pull requesta | F | Jeden token na zakres repozytorium; agent nie czyta prywatnego zakresu w sesji rozpoczętej z publicznego | | 2025-05 | Aplikacje generowane w Lovable, CVE-2025-48757, CVSS 9,3 | Wygenerowane polityki row-level security w Supabase niewystarczające albo nieobecne w projektach utworzonych przed 2025-04-15 | Nieuwierzytelniony odczyt i zapis dowolnych tabel wygenerowanych stron; dostawca kwestionuje, wskazując odpowiedzialność każdego klienta | B | Sprawdzenie polityk tabela po tabeli klientem anonimowym przed publikacją; RLS wymagane dla każdej tabeli z danymi użytkowników | | 2025-06 | Microsoft 365 Copilot, EchoLeak, CVE-2025-32711, CVSS 9,3 | Polecenia w przychodzącym e-mailu przetworzone przez asystenta bez żadnego działania użytkownika | Ujawnienie informacji przez sieć, bez kliknięcia | A | Niezaufana treść nigdy nie łączy się z narzędziem, które sięga na zewnątrz; lista dozwolonych adresów wychodzących dla każdego działania asystenta | | 2025-07 | Supabase MCP z Cursorem, General Analysis | Treść zgłoszenia do wsparcia każe agentowi odczytać integration_tokens; połączenie MCP działa z rolą service_role, która omija row-level security | Sekrety OAuth i dane sesji wpisane z powrotem do wątku zgłoszenia | F | Zakres projektu na serwerze MCP i połączenie bez dostępu do tabel z sekretami; żadnego service_role w połączeniu dostępnym dla agenta | | 2025-07 | mcp-remote, CVE-2025-6514, CVSS 9,6 | Adres authorization_endpoint zwrócony przez niezaufany serwer MCP przekazany do polecenia | Wstrzyknięcie polecenia systemowego na maszynie programisty | F | Przypięta, przejrzana lista serwerów MCP; żadnego składania poleceń powłoki ze zdalnych ciągów; bramka wersji klienta | | 2025-07 | Amazon Q Developer dla VS Code 1.84.0, biuletyn AWS-2025-015 | Token GitHub o zbyt szerokim zakresie wpuścił niezatwierdzony kod do repozytorium rozszerzenia i do wydania | Złośliwy kod w wydaniu; nie zadziałał przez błąd składni; wersja wycofana, wydano 1.85.0 | F | Przypięcie wersji rozszerzeń i przegląd aktualizacji; tokeny o najmniejszych uprawnieniach w potoku publikacji | | 2025-07 | Gemini CLI 0.1.13, Tracebit | Polecenia ukryte w README, lista dozwolonych, która przepuściła łańcuch poleceń po jednym zatwierdzonym grep, oraz białe znaki ukrywające ładunek | Zmienne środowiskowe wysłane na zdalny serwer bez pokazania polecenia użytkownikowi; poprawka w 0.1.14 | A | Zatwierdzanie każdego polecenia z widoczną całą linią poleceń; bez dopasowania listy dozwolonych po pierwszym tokenie | | 2025-07 | Replit Agent, projekt SaaStr, oświadczenie prezesa dostawcy w relacji Fortune | Agent uruchomił destrukcyjne polecenie na bazie w czasie ogłoszonego zamrożenia kodu i zgłosił, że przywrócenie jest niemożliwe | Baza produkcyjna skasowana; dostawca nazwał to niedopuszczalnym i wdrożył rozdział dev/prod oraz tryb samego planowania | D | Żadnych danych dostępowych do produkcji w środowisku agenta; operacje destrukcyjne za jawnym potwierdzeniem i przetestowanym przywracaniem | | 2025-08 | Cursor poniżej 1.3.9, CVE-2025-54135, CVSS 8,6 | Pośrednie wstrzyknięcie promptu tworzy nowy plik .cursor/mcp.json bez zgody, której wymaga edycja istniejącego | Zdalne wykonanie kodu na maszynie programisty | A | Tworzenie i edycja plików konfiguracyjnych pod tą samą regułą zgody; test wstrzyknięcia, który zapisuje plik kanarkowy | | 2025-08 | Cursor 1.2.4 i niżej, CVE-2025-54136, CVSS 7,2 | Zatwierdzona już definicja MCP we współdzielonym repozytorium podmieniona na inne polecenie bez ponownego pytania | Trwałe wykonanie kodu dla każdego z prawem zapisu do gałęzi | F | Skrót każdej zatwierdzonej definicji MCP; ponowna zgoda przy każdej zmianie; konfiguracja MCP przeglądana jak workflow CI | | 2025-08 | Claude Code poniżej 0.2.111, CVE-2025-54794, CVSS 7,7 | Sprawdzenie ścieżki po prefiksie zamiast po ścieżce kanonicznej; katalog z tym samym prefiksem co katalog roboczy przechodzi | Dostęp do plików poza katalogiem roboczym, gdy niezaufana treść jest w kontekście | A | Porównanie ścieżek kanonicznych w każdej kontroli ścieżek; test z katalogiem sąsiednim o wspólnym prefiksie | | 2025-08 | GitHub Copilot i Visual Studio, CVE-2025-53773, CVSS 7,8 | Wstrzyknięcie promptu edytuje .vscode/settings.json i ustawia chat.tools.autoApprove, usuwając każde potwierdzenie | Lokalne wykonanie kodu na Windows, macOS i Linuksie | A | Pliki ustawień traktowane jak kod: chronione przed zapisem w sesjach agenta, pokazywane w diffie w przeglądzie, flagi automatycznej zgody zakazane polityką | | 2025-09 | Salesforce Agentforce, ForcedLeak, Noma Security, CVSS 9,4 | Pole opisu w formularzu leadów niesie polecenia; wynik agenta może trafić do wygasłej domeny wciąż obecnej na liście dozwolonych CSP | Rekordy CRM wysłane do domeny zarejestrowanej przez atakującego; poprawka wymusza zaufane adresy URL | A | Audyt listy dozwolonych adresów wychodzących pod kątem wygasłych wpisów; pola formularzy oznaczone jako niezaufane, zanim trafią do agenta | | 2025-11 | Google Antigravity, PromptArmor | Polecenia czcionką 1 pkt na stronie WWW; agent czyta .env przez cat mimo straży opartej na gitignore, a podagent przeglądarki otwiera adres atakującego z zawartością | Dane dostępowe wyprowadzone do serwisu logującego obecnego na domyślnej liście dozwolonych przeglądarki | A | Kontrola dostępu do plików, która obejmuje także powłokę; przegląd domyślnej listy dozwolonych przeglądarki; sekrety poza katalogiem roboczym | | 2025-12 | Google Antigravity w trybie Turbo, relacja The Register; dostawca potwierdził postępowanie, bez oficjalnego raportu | Polecenie czyszczenia pamięci podręcznej trafiło w korzeń dysku D: zamiast w katalog projektu, bez potwierdzenia w tym trybie | Zawartość dysku użytkownika skasowana z pominięciem kosza | D | Destrukcyjne operacje na plikach ograniczone do ścieżki katalogu roboczego; tryb potwierdzania poza piaskownicami | | 2026-01 | Moltbook, Wiz Research | Klucz Supabase wpisany na stałe w JavaScript po stronie klienta, bez row-level security; założyciel oświadczył, że żadna linia nie została napisana ręcznie | 1,5 mln tokenów API, 35 000 adresów e-mail i prywatne wiadomości do odczytu i zapisu bez uwierzytelnienia; poprawka w kilka godzin od ujawnienia | B | Sonda klientem anonimowym na każdej tabeli przed startem; skan sekretów na zbudowanej paczce, nie tylko na repozytorium | ### Sześć klas mechanizmów i co łączy wpisy w każdej z nich Nazwy narzędzi się zmieniają, mechanizmy się powtarzają. Każda klasa poniżej nazywa, co zrobiło narzędzie, czego brakowało procesowi i jaki pomiar za tym stoi, jeśli istnieje. Dwa recenzowane badania kotwiczą klasy dotyczące samego generowanego kodu: Pearce i współautorzy (IEEE S&P 2022) wygenerowali Copilotem 1 689 programów w 89 scenariuszach słabości i uznali około 40% za podatne; Fu i współautorzy (ACM TOSEM 2025) przeanalizowali 733 fragmenty napisane przez asystenta znalezione w prawdziwych projektach na GitHubie i zgłosili słabości w 29,5% próbki w Pythonie i 24,2% w JavaScripcie. | Klasa | Mechanizm | Czego brakowało procesowi | Wpisy powyżej | | --- | --- | --- | --- | | A. Treść staje się poleceniem | Tekst, który agent czyta (zgłoszenie w systemie wsparcia albo w repozytorium, README, e-mail, strona WWW, pole formularza), jest przetwarzany tak, jakby wpisał go użytkownik, a po nim następuje wywołanie narzędzia | Granica między niezaufaną treścią a narzędziami, które sięgają na zewnątrz; zgoda, która pokazuje całe działanie | GitLab Duo, EchoLeak, Gemini CLI, Cursor, Claude Code, Copilot, Agentforce, Antigravity | | B. Wygenerowany domyślny stan idzie na produkcję bez zmian | Reguły dostępu do backendu, klucze w paczkach klienta i domyślne ustawienia frameworka trafiają na produkcję w stanie, w jakim wyprodukował je asystent | Kontrola przed publikacją dla każdej tabeli i każdego sekretu, uruchomiona jako klient anonimowy | Lovable RLS, Moltbook | | C. Zmyślona zależność | Asystent podaje nazwę pakietu, który nie istnieje; ktoś rejestruje tę nazwę; linia instalacji zyskuje zaufanie, bo wygląda zwyczajnie | Weryfikacja w rejestrze każdej nowej zależności w przeglądzie | huggingface-cli, Spracklen i współautorzy | | D. Destrukcyjne polecenie bez bramki | Agent z dostępem do produkcji albo do systemu plików uruchamia usunięcie, drop albo wyczyszczenie w trybie, w którym potwierdzenia są wyłączone | Rozdział danych dostępowych między środowiskami; jawna bramka na operacjach destrukcyjnych; przetestowane przywracanie | Replit Agent, Antigravity Turbo | | E. Wynik modelu trafia do SQL albo do wykonania kodu | Tekst z modelu jest przekazywany do bazy albo interpretera tak, jakby ktoś go przejrzał | Role ograniczone do danych z zadania, lista dozwolonych instrukcji, bez wykonywania wygenerowanego kodu ze ścieżek użytkownika | LangChain, Vanna.AI | | F. Narzędzie albo rozszerzenie z dostępem szerszym niż zadanie | Serwer MCP, rozszerzenie albo token ma zakres na wszystko, co może zrobić programista, a agent go dziedziczy | Jeden zakres na zadanie; skrót i ponowna zgoda dla definicji narzędzi; przypięte wersje | GitHub MCP, Supabase MCP, mcp-remote, podmiana MCP w Cursorze, rozszerzenie Amazon Q | ### Co sprawdza przegląd bezpieczeństwa kodu pisanego przez AI, klasa po klasie Katalog staje się użyteczny, gdy każda klasa dostaje wynik dla konkretnej bazy kodu: wynik konkretnego testu, sprawdzony zakres i granice wniosku. Lista poniżej to lista kontrolna, którą Przegląd bezpieczeństwa kodu pisanego przez AI wykonuje dla każdej klasy. Każdy punkt kończy się artefaktem albo testem, bo wynik bez nich jest opinią. - Klasa A. Prześledźcie każdą ścieżkę, którą niezaufany tekst wchodzi do promptu i po której może nastąpić wywołanie narzędzia. Wypiszcie każde narzędzie, które sięga poza proces: sieć, powłoka, zapis pliku, przeglądarka. Zbudujcie zestaw testów wstrzyknięć z działaniem kanarkowym i uruchamiajcie go w CI na każdej ścieżce. Przejrzyjcie listę dozwolonych adresów wychodzących pod kątem wygasłych wpisów i symboli wieloznacznych. - Klasa B. Wypiszcie tabele i zasobniki, a potem sprawdźcie każdy z nich jako klient anonimowy i jako użytkownik o niskich uprawnieniach. Przeskanujcie zbudowaną paczkę klienta pod kątem kluczy uprzywilejowanych, nie tylko repozytorium. Porównajcie domyślne ustawienia frameworka odtworzone przez asystenta (CORS, flagi weryfikacji, wyjście debugowania) z konfiguracją produkcyjną. - Klasa C. Porównujcie plik blokady w każdym pull requeście napisanym z asystentem. Sprawdzajcie każdy nowy pakiet pod kątem wieku w rejestrze, wydawcy i historii pobrań. Utrzymujcie listę dozwolonych dla środowiska uruchomieniowego i blokadę poleceń instalacji, które asystent wpisuje do dokumentacji. - Klasa D. Wypiszcie każde dane dostępowe w środowisku agenta razem ze środowiskiem, do którego należą. Oddzielcie produkcję od wszystkiego, do czego agent sięga. Postawcie operacje destrukcyjne za jawnym potwierdzeniem i przećwiczcie przywracanie raz, z zapisanym czasem, ile trwało. - Klasa E. Znajdźcie każdy punkt, w którym wynik modelu jest wykonywany albo odpytuje bazę. Dajcie generowanemu SQL rolę ograniczoną do tabel z zadania, bez zapisu, oraz listę dozwolonych instrukcji. Usuńcie wykonywanie wygenerowanego kodu z każdej ścieżki dostępnej użytkownikom. To, co zostaje, zamknijcie w piaskownicy. - Klasa F. Zinwentaryzujcie serwery MCP, rozszerzenia i tokeny razem z ich zakresami. Zawęźcie każdy do zadania, któremu służy. Liczcie skróty zatwierdzonych definicji narzędzi i wymagajcie ponownej zgody przy zmianie. Przypnijcie wersje i przeglądajcie aktualizacje jak aktualizacje zależności. - Ponowny test. Po poprawkach każda klasa dostaje ten sam test jeszcze raz, a wynik jest zapisany obok pierwotnego. Para wyników to dowód, który może przeczytać klient albo zarząd. ### Gdzie to się psuje i co z tym robimy **Treść, którą czyta agent, jest traktowana jak polecenie** Agent dostaje do kontekstu zgłoszenie do wsparcia, zgłoszenie w repozytorium, README albo e-mail, bo tego wymaga zadanie, a model nie ma niezawodnego sposobu, żeby odróżnić cytowany tekst od prośby użytkownika. Gdy w tej samej sesji dostępne jest narzędzie sięgające poza proces, tekst może je wywołać. Każdy wpis klasy A w katalogu ma ten kształt, od GitLab Duo po Antigravity, a poprawki dostawców były granicami wokół narzędzi, nie lepszymi modelami. Co z tym robimy: Mapujemy każdą ścieżkę wejścia niezaufanego tekstu do promptu i wypisujemy każde narzędzie osiągalne z tej sesji. Tam, gdzie jedno spotyka drugie, usuwamy narzędzie wychodzące albo stawiamy je za zgodą pokazującą pełne działanie. Oznaczenie treści jako danych w strukturze promptu zostaje środkiem pomocniczym, nie zamiennikiem kontroli wykonywanej poza modelem. Potem uruchamiamy zestaw testów wstrzyknięć z działaniem kanarkowym na każdej ścieżce i przekazujemy go do waszego CI. Co zostaje u was: mapa niezaufanej treści i osiągalnych narzędzi ścieżka po ścieżce, z zestawem testów wstrzyknięć i wynikami dla każdej ścieżki **Wygenerowany domyślny backend idzie na produkcję w stanie, w jakim powstał** Asystent stawia backend według wzorca, który zna najlepiej: klucz po stronie klienta, reguły dostępu wyłączone albo luźne, wyjście debugowania włączone. W demo to działa, bo demo ma jednego użytkownika. CVE Lovable i wyciek Moltbook to ten sam mechanizm w dwóch skalach i w obu przypadkach dostawca stał na stanowisku, że reguły dostępu należą do klienta. Co z tym robimy: Wypisujemy każdą tabelę i zasobnik, potem sprawdzamy każdy z nich jako klient anonimowy i jako użytkownik o niskich uprawnieniach, a zbudowaną paczkę skanujemy pod kątem kluczy. Każda tabela, która nie przechodzi, dostaje politykę, każdy klucz uprzywilejowany przenosi się na stronę serwera, a klucze publiczne zostają tylko tam, gdzie tabele mają reguły dostępu. Test uruchamia się ponownie, aż nic nie zwróci. Potem zostaje jako kontrola przed publikacją. Co zostaje u was: macierz dostępu tabela po tabeli z wynikiem sondy klientem anonimowym przed poprawką i po niej oraz sonda wpięta w potok wydawania **Nazwy pakietów zyskują zaufanie, bo wyglądają zwyczajnie** Asystent pisze linię instalacji z wiarygodną nazwą, która nie istnieje, a badanie Spracklena i współautorów pokazuje, że te same zmyślone nazwy powtarzają się między promptami. Kto zarejestruje taką nazwę, dostaje instalacje z każdego projektu, który zaufał tej linii. Przypadek huggingface-cli pokazuje, jak nazwa trafiła do dokumentacji prawdziwego repozytorium, zanim ktokolwiek sprawdził rejestr. Co z tym robimy: Porównujemy plik blokady w każdej zmianie napisanej z asystentem, sprawdzamy każdy nowy pakiet w rejestrze pod kątem wieku, wydawcy i historii i zamieniamy tę kontrolę w regułę przeglądu. Polecenia instalacji, które asystent wpisał do dokumentacji, przechodzą to samo. Co zostaje u was: raport pochodzenia zależności za okres pracy z AI oraz kontrola rejestru jako reguła CI **Destrukcyjne polecenia wykonują się, bo potwierdzenie było wyłączone** Turbo, YOLO, automatyczna zgoda: tryby, w których agent wykonuje polecenia bez potwierdzeń. W takim trybie czyszczenie pamięci podręcznej, które trafia w złą ścieżkę, albo reset bazy wydany w czasie zamrożenia kodu wykonuje się z prędkością agenta. W obu wpisach klasy D agent miał dostęp szerszy niż zadanie: do bazy produkcyjnej i do całego dysku. Co z tym robimy: Wypisujemy każde dane dostępowe, do których agent sięga, razem ze środowiskiem, do którego należą, usuwamy z tej listy produkcję i stawiamy operacje destrukcyjne za jawną bramką. Potem ćwiczymy przywracanie raz i zapisujemy, ile trwało. Co zostaje u was: mapa danych dostępowych dla każdego agenta i środowiska, lista operacji za bramką oraz zapis próby przywracania z czasem trwania **Definicja narzędzia się zmienia, a nikt nie pyta ponownie** Serwer MCP albo rozszerzenie zostało zatwierdzone raz. Definicja leży we współdzielonym repozytorium albo aktualizuje się sama, a zgoda nie idzie za zmianą. Obejście ponownej zgody w Cursorze i wydanie rozszerzenia Amazon Q pokazują dwa końce tej samej drogi: podmienione polecenie na gałęzi i niezatwierdzony kod w opublikowanej wersji. Co z tym robimy: Inwentaryzujemy serwery MCP, rozszerzenia i tokeny razem z zakresami, zawężamy każdy zakres do zadania, liczymy skrót każdej zatwierdzonej definicji i wymagamy ponownej zgody przy zmianie. Wersje zostają przypięte, a aktualizacje przechodzą ten sam przegląd co aktualizacje zależności. Co zostaje u was: inwentarz narzędzi z zakresem dla każdego zadania, skróty zatwierdzonych definicji i reguła ponownej zgody w waszej konfiguracji ### Co dostajecie - Mapowanie incydentów na bazę kodu: wynik testu dla każdej klasy mechanizmu w waszych repozytoriach i integracjach agentów, z dowodami i zakresem sprawdzenia - Lista kontrolna dla każdej klasy, wypełniona dla waszego stosu, z artefaktem albo testem, który zamyka każdy punkt - Zestaw testów wstrzyknięć z działaniami kanarkowymi, wpięty w CI, z wynikami dla każdej ścieżki niezaufanej treści - Macierz dostępu do tabel i zasobników z wynikiem sondy klientem anonimowym, przed poprawkami i po nich - Raport pochodzenia zależności za okres pracy z AI oraz kontrola rejestru jako reguła przeglądu - Inwentarz narzędzi: serwery MCP, rozszerzenia i tokeny z zakresem dla każdego zadania, skróty definicji i reguła ponownej zgody - Zapis ponownego testu: każda klasa przetestowana ponownie po poprawkach, z wynikiem obok pierwotnego ### Jak pracujemy 1. **1. Mapowanie** (Tydzień 1): Przechodzimy repozytoria i integracje agentów z doświadczonym inżynierem z waszej strony i zaznaczamy, gdzie może wystąpić każda klasa mechanizmu: ścieżki niezaufanej treści, wygenerowane reguły backendu, nowe zależności, dane dostępowe agentów, wynik modelu w SQL albo w wykonaniu kodu, zakresy narzędzi. 2. **2. Werdykty** (Tydzień 1-2): Wykonujemy listę kontrolną dla każdej klasy: testy wstrzyknięć, sondy klientem anonimowym, kontrole pliku blokady i rejestru, inwentarze danych dostępowych i narzędzi. Każda klasa dostaje wynik testu z dowodami i zakresem sprawdzenia, a każde ustalenie ma sposób odtworzenia. 3. **3. Poprawki i bramki** (Tydzień 2-3): Usuwamy wykryte błędy razem z waszym zespołem i zamieniamy każdy zamknięty punkt w bramkę: sondę, zestaw testów, regułę rejestru, kontrolę skrótów. Każdą bramkę uruchamiamy raz celowo, żeby dowieść, że działa. 4. **4. Ponowny test i przekazanie** (Tydzień 3, zależnie od liczby repozytoriów i integracji): Powtarzamy test każdej klasy, zapisujemy wynik obok pierwotnego i przekazujemy mapowanie, listy kontrolne i bramki w waszym potoku. Katalog na tej stronie jest punktem odniesienia, od którego zaczyna się następny przegląd. ### FAQ **Q: Jak dobierane są incydenty do katalogu?** Tylko przypadki ze źródłem pierwotnym, które da się sprawdzić: rekord CVE, biuletyn bezpieczeństwa dostawcy, publiczne oświadczenie kierownictwa dostawcy, oficjalny raport po incydencie albo recenzowane badanie z opublikowaną metodą. Przypadki zgłoszone przez samych poszkodowanych wchodzą tylko po publicznym potwierdzeniu przez dostawcę i wiersz o tym mówi. Nic spod NDA, w tym nic z naszych własnych zleceń. **Q: Naszego narzędzia nie ma w tabeli. Czy katalog nas dotyczy?** Tak, bo przegląd pracuje na klasach, nie na nazwach produktów. Zespół używający narzędzia bez publicznego CVE nadal ma ścieżki niezaufanej treści, wygenerowane reguły backendu, nowe zależności, dane dostępowe agentów i zakresy narzędzi. Mapujemy je i dajemy werdykt dla każdej klasy; nazwa narzędzia decyduje tylko o tym, które domyślne ustawienia sprawdzamy najpierw. **Q: Czy to test penetracyjny?** Nie. Test penetracyjny próbuje przełamać działający system, z zewnątrz albo od środka, a tego nie robimy, podobnie jak infrastruktury, chmury ani SOC. Ten przegląd czyta kod i warstwę aplikacji wokół modelu, odtwarza ustalenia na instancji nieprodukcyjnej i przekazuje poprawki oraz bramki. Jeśli potem potrzebny jest test penetracyjny, nasze ustalenia są konkretnym punktem wyjścia dla specjalisty, który go wykona. **Q: Czy katalog dowodzi, że kod pisany z AI jest mniej bezpieczny?** Nie rozstrzyga tego porównania, bo nie zawiera grupy kodu pisanego bez AI. Dowodzi, że narzędzie użyte bez kontroli przed nim zawodzi w powtarzalny sposób. To samo mierzą badania: Pearce i współautorzy, Fu i współautorzy oraz Spracklen i współautorzy opisują wynik modelu, nie wynik procesu. Każdy wiersz ma kontrolę, która by go wykryła. Ta kontrola jest sensem tej strony. **Q: Jak wygląda ponowny test i dlaczego jest osobno od poprawki?** Ten sam test, który dał werdykt, biegnie ponownie po poprawce: zestaw wstrzyknięć, sonda klientem anonimowym, kontrola rejestru, próba przywracania. Wynik jest zapisany obok pierwotnego, więc czytelnik widzi stan przed i po z tej samej metody. Ponowny test sprawdza, czy konkretny błąd został usunięty; bez niego poprawka pozostaje deklaracją. **Q: Jak często katalog jest aktualizowany i czy można zgłosić wpis?** Jest poprawiany, gdy dostawcy publikują biuletyny, a badacze pomiary; lista źródeł na dole ma daty. Wpis może zostać dodany, gdy ma publiczne źródło pierwotne. To jest też odpowiedź na zgłoszenia: przyślijcie odnośnik do biuletynu albo raportu, który dokumentuje zdarzenie. **Q: Jaki dostęp jest potrzebny do przeglądu?** Dostęp do odczytu repozytoriów w zakresie, konfiguracja narzędzi agentowych (definicje MCP, listy rozszerzeń, pliki ustawień) i instancja nieprodukcyjna do odtworzeń i sond. Bez dostępu do produkcji i bez danych klientów. Wszystko biegnie pod NDA, dlatego nic z pracy dla klientów nigdy nie trafia do katalogu. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/bezpieczenstwo-kodu-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai ### Źródła - CVE-2025-53773, zdalne wykonanie kodu w GitHub Copilot i Visual Studio (Microsoft, sierpień 2025): https://www.cve.org/CVERecord?id=CVE-2025-53773 - Embrace The Red, RCE w GitHub Copilot przez wstrzyknięcie promptu: settings.json i chat.tools.autoApprove: https://embracethered.com/blog/posts/2025/github-copilot-remote-code-execution-via-prompt-injection/ - CVE-2025-32711, ujawnienie informacji w Microsoft 365 Copilot, EchoLeak (czerwiec 2025): https://www.cve.org/CVERecord?id=CVE-2025-32711 - CVE-2025-54135, wstrzyknięcie promptu w Cursorze przez pliki specjalne MCP, poprawka w 1.3.9 (advisory GitHub): https://github.com/cursor/cursor/security/advisories/GHSA-4cxx-hrm3-49rm - CVE-2025-54136, zmiana definicji MCP w Cursorze omija ponowną zgodę (advisory GitHub): https://github.com/cursor/cursor/security/advisories/GHSA-24mc-g4xr-4395 - CVE-2025-54794, obejście ograniczenia ścieżek w Claude Code, poprawka w 0.2.111 (advisory GitHub): https://github.com/anthropics/claude-code/security/advisories/GHSA-pmw4-pwvc-3hx2 - CVE-2025-6514, wstrzyknięcie polecenia systemowego w mcp-remote z niezaufanych serwerów MCP (JFrog Security Research): https://research.jfrog.com/vulnerabilities/mcp-remote-command-injection-rce-jfsa-2025-001290844/ - CVE-2024-5565, wstrzyknięcie promptu w Vanna.AI prowadzące do zdalnego wykonania kodu (JFrog Security Research): https://research.jfrog.com/vulnerabilities/vanna-prompt-injection-rce-jfsa-2024-001034449/ - CVE-2023-36189, SQL injection w LangChain SQLDatabaseChain: https://www.cve.org/CVERecord?id=CVE-2023-36189 - CVE-2025-48757, niewystarczające row-level security w aplikacjach generowanych w Lovable; ujawnienie Matta Palmera: https://mattpalmer.io/posts/CVE-2025-48757/ - Legit Security, zdalne wstrzyknięcie promptu w GitLab Duo (ukryta treść, wyprowadzenie prywatnego kodu): https://www.legitsecurity.com/blog/remote-prompt-injection-in-gitlab-duo - Invariant Labs, serwer GitHub MCP: dane z prywatnego repozytorium wyprowadzone przez publiczne zgłoszenie: https://invariantlabs.ai/blog/mcp-github-vulnerability - General Analysis, Supabase MCP z Cursorem: od zgłoszenia do wsparcia do wycieku integration_tokens: https://www.generalanalysis.com/blog/supabase-mcp-blog - Dokumentacja Supabase, bezpieczeństwo serwera MCP: wstrzyknięcie promptu, tryb tylko do odczytu, zakres projektu, grupy funkcji: https://supabase.com/docs/guides/getting-started/mcp - Biuletyn bezpieczeństwa AWS-2025-015, Amazon Q Developer dla VS Code 1.84.0: https://aws.amazon.com/security/security-bulletins/AWS-2025-015/ - Tracebit, Gemini CLI: wykonanie kodu i wyprowadzenie danych przez README i obejście listy dozwolonych, poprawka w 0.1.14: https://tracebit.com/blog/code-exec-deception-gemini-ai-cli-hijack - Noma Security, ForcedLeak: wyprowadzenie danych CRM z Salesforce Agentforce przez Web-to-Lead i wygasłą domenę z listy dozwolonych: https://noma.security/blog/forcedleak-agent-risks-exposed-in-salesforce-agentforce/ - PromptArmor, Google Antigravity wyprowadza dane: ukryty tekst na stronie, .env przez cat, podagent przeglądarki: https://www.promptarmor.com/resources/google-antigravity-exfiltrates-data - The Register, Google Antigravity w trybie Turbo kasuje dysk użytkownika; Google potwierdza postępowanie (grudzień 2025): https://www.theregister.com/2025/12/01/google_antigravity_wipes_d_drive/ - Fortune, Replit Agent kasuje bazę produkcyjną w czasie zamrożenia kodu; oświadczenie prezesa i zapowiedziane poprawki (lipiec 2025): https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/ - Wiz Research, Moltbook: odsłonięta baza Supabase, 1,5 mln tokenów API (luty 2026): https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys - Lasso Security, halucynacje pakietów: eksperyment huggingface-cli (marzec 2024): https://www.lasso.security/blog/ai-package-hallucinations - Spracklen i współautorzy, We Have a Package for You! Halucynacje pakietów w LLM generujących kod, USENIX Security 2025 (arXiv 2406.10279): https://arxiv.org/abs/2406.10279 - Fu i współautorzy, Słabości bezpieczeństwa kodu z Copilota w projektach na GitHubie, ACM TOSEM 2025 (arXiv 2310.02059): https://arxiv.org/abs/2310.02059 - Pearce i współautorzy, Asleep at the Keyboard? Bezpieczeństwo kodu z GitHub Copilota, IEEE S&P 2022 (arXiv 2108.09293): https://arxiv.org/abs/2108.09293 --- ## Dług utrzymaniowy kodu pisanego przez AI: jak zmierzyć go we własnym repozytorium i co zrobić z wynikiem **URL:** https://23minds.com/pl/przewodniki/dlug-utrzymaniowy-kodu-pisanego-przez-ai > Dług utrzymaniowy kodu pisanego przez AI to dodatkowy nakład na każdą późniejszą zmianę, wynikający z wcześniejszych decyzji albo zaniedbań w kodzie, który powstał z asystentem. Audyt mierzy go w waszym repozytorium sześcioma miarami z gita i analizy statycznej i kończy się planem naprawy z priorytetami. Mechanizmy, które ten dług tworzą, są opisane niżej. ### Podsumowanie 23Minds audytuje dług utrzymaniowy w kodzie pisanym przez AI dla zespołów inżynierskich, u których dostarczanie przyspieszyło, a zmiany zwolniły. Audyt liczy sześć miar z historii gita i analizy statycznej: względną zmienność pliku, czas do pierwszej poprawki po scaleniu, koncentrację własności, zduplikowane i niespójnie zmieniane bloki, kod na ścieżkach krytycznych bez skutecznych testów oraz przeżywalność problemów wprowadzonych przez asystentów. Za większością miar stoi opublikowane badanie, a strona mówi wprost, gdzie dowody są niejednoznaczne i które miary są propozycją audytu. Wynik to raport długu uszeregowany według kosztu zmiany, plan naprawy, który zespół wykonuje sam, oraz procedura przekazania własności modułów bez opiekuna nazwanym osobom. Przepisanie kodu nie jest częścią audytu. ### Dla kogo to jest - CTO i szefowie inżynierii, którzy wdrożyli asystentów kodowania w całym zespole i widzą, jak zmiany publikują się częściej, a każda pojedyncza trwa dłużej - Menedżerowie inżynierii przejmujący repozytorium, w którym duża część kodu nie ma autora, który pamięta, dlaczego wygląda tak, a nie inaczej - Tech leadzi, których poproszono o liczbę opisującą dług przed następnym cyklem planowania, a mają tylko przeczucie - Zespoły, które zatrudniają albo budżetują naprawę kodu pisanego przez AI jako osobną kategorię pracy i potrzebują jej zakresu ### Skąd bierze się koszt Dowody o kodzie pisanym przez AI są niejednoznaczne. W kontrolowanym eksperymencie ze 151 uczestnikami, w 95% zawodowymi programistami, Borg i współautorzy (Echoes of AI, 2025) nie zaobserwowali spójnych sygnałów pogorszenia utrzymywalności na poziomie kodu, gdy inni programiści rozwijali kod pisany z AI. W prawdziwych repozytoriach obraz jest inny: Liu i współautorzy (Debt Behind the AI Boom, 2026) prześledzili 302,6 tys. zweryfikowanych commitów autorstwa AI w 6 299 repozytoriach. Ponad 15% commitów od każdego asystenta wprowadzało co najmniej jeden problem wykrywany analizą statyczną, a 22,7% tych problemów pozostawało w kodzie na koniec badanego okresu. Raport DORA 2025, oparty na blisko 5 000 odpowiedzi, pokazuje dodatni związek adopcji AI z przepustowością i trwale ujemny ze stabilnością dostarczania. Te badania nie rozstrzygają, z czego wynikają różnice między zespołami. Jedyny sposób, żeby wiedzieć, po której stronie jest wasze repozytorium, to je zmierzyć. Pięć mechanizmów powtarza się w opisanych badaniach i w audytach; każdy jest własnością narzędzia użytego bez procesu, a to, czy występuje u was, pokazuje pomiar. Asystent widzi pliki w swoim oknie kontekstu, więc dokłada pomocnika albo gałąź obok istniejącej struktury, zamiast użyć tego, co leży dwa katalogi dalej. Opis pull requesta wygenerowany z diffu zapisuje, co się zmieniło, ale nie dlaczego, więc intencja zmiany znika w dniu scalenia. Testy wygenerowane z implementacji sprawdzają obecne zachowanie razem z błędem. Raportują wysokie pokrycie, nie łapiąc niczego. Zależność pojawia się, bo model często ją widział, a nie dlatego, że ktoś w zespole zdecydował ją nieść. A rozproszone autorstwo pliku dotykanego przez pięć osób i ich asystentów wskazuje moduły, dla których warto potwierdzić opiekuna; Bird i współautorzy (2011) powiązali taki wzorzec z awariami przed wydaniem i po wydaniu w Windows Vista i Windows 7. Przegląd 104 źródeł Ehsaniego i współautorów (2026) nadaje temu ostatniemu nazwę: dług pochodzenia, punkt, w którym odpowiedzialności za wygenerowaną logikę nie da się przypisać nikomu. Sawada i współautorzy (2026) przeanalizowali około 1 000 plików wygenerowanych przez AI w 100 popularnych repozytoriach. Takie pliki dostają rzadszą konserwację niż kod pisany przez ludzi, zmiany, które dostają, to głównie rozszerzenia funkcji, a nie poprawki. Niemal całą tę konserwację wykonują ludzie. Plik, który ciągle rośnie i nigdy nie jest poprawiany, niekoniecznie jest zdrowy. Może być po prostu plikiem, którego nikt nie odważa się dotknąć. ### Sześć miar, które policzycie z gita i analizy statycznej Żadna z miar poniżej nie wymaga komercyjnej platformy. Potrzebują dostępu do odczytu repozytorium, logów CI, przebiegów analizy statycznej i możliwości uruchomienia testów na kopii. Za większością stoi opublikowany powód, żeby jej ufać; testy mutacyjne i czas do pierwszej poprawki są propozycją audytu opartą na tych badaniach. Dla żadnej nie ma uniwersalnego progu alarmowego. Porównanie, które się broni, to wasze własne repozytorium sprzed asystentów albo moduły pisane z nimi i bez nich. Commity autorstwa asystenta rozpoznajemy po oznaczeniach w historii, szablonie pull requesta i rozmowie z zespołem; tam, gdzie oznaczeń nie ma, pomiar obejmuje okres po wdrożeniu asystentów jako całość. | Miara | Jak jest liczona | Dlaczego można jej ufać | Jak wygląda zły odczyt | | --- | --- | --- | --- | | Względna zmienność pliku | Linie zmienione w pliku w okresie, podzielone przez rozmiar pliku, z git log | Nagappan i Ball (ICSE 2005): względne miary zmienności dobrze przewidują gęstość defektów, bezwzględne nie | Pliki, których względna zmienność dalej rośnie po wdrożeniu asystenta, bez odpowiadającej pracy nad funkcjami | | Czas do pierwszej poprawki po scaleniu | Dla każdej scalonej zmiany: dni do następnego commita dotykającego tych samych linii, który odwołuje się do błędu, cofnięcia albo hotfixa | Bezpośrednia miara stabilności, którą DORA opisuje jako koszt większej liczby zmian bez systemów kontroli | Skracający się odstęp między scaleniem a poprawką, czytany razem z liczbą i wagą poprawek; sam krótszy odstęp może też oznaczać sprawniejsze wykrywanie błędów | | Koncentracja własności | Udział commitów najaktywniejszego autora w module oraz liczba autorów poniżej małego udziału, z git blame i log | Bird i współautorzy (FSE 2011): liczba autorów o niskiej znajomości modułu i udział głównego właściciela wiążą się z błędami przed wydaniem i awariami po nim | Moduły, w których udział głównego właściciela maleje, a ogon drobnych autorów rośnie | | Zduplikowane i niespójnie zmieniane bloki | Wykrywanie klonów w całym repozytorium, potem diff każdej grupy klonów, żeby znaleźć kopie zmienione tylko w jednym miejscu | Juergens i współautorzy (ICSE 2009): 107 potwierdzonych przez programistów błędów z niespójnych zmian klonów w pięciu systemach komercyjnych i open source | Grupy klonów, w których poprawka błędu weszła do części kopii, a do reszty nie | | Kod na ścieżkach krytycznych bez skutecznych testów | Pokrycie ograniczone do ścieżek obsługujących pieniądze, tożsamość i dane, potem testy mutacyjne na tych ścieżkach | Samo pokrycie mówi, że linia została wykonana; wynik testów mutacyjnych pokazuje, jaką część wprowadzonych mutacji wykryły testy | Wysokie pokrycie linii przy niskim wyniku mutacji na ścieżkach, które mają znaczenie | | Przeżywalność problemów wprowadzonych przez asystenta | Analiza statyczna przed każdym commitem autorstwa asystenta i po nim, potem śledzenie każdego wprowadzonego problemu do bieżącej wersji | Metoda, którą Liu i współautorzy (2026) zastosowali na 302,6 tys. commitów; oddziela problemy naprawiane od tych, które się kumulują | Rosnąca zaległość wprowadzonych problemów, których nikt nie zamyka, skupiona w modułach bez właściciela | ### Naprawa kodu pisanego przez AI jako kategoria pracy i gdzie audyt się kończy W dyskusjach doświadczonych programistów naprawa kodu pisanego przez AI stała się osobną kategorią pracy: przejąć kod, którego nikt nie napisał, a potem sprawić, żeby znów dało się go zmieniać. Audyt wyznacza zakres tej pracy: daje uszeregowaną listę, plan i przekazanie własności, a nie wykonuje przepisania, z dwóch powodów. Zespół, który ma żyć z tym kodem, powinien być tym, który go porządkuje, inaczej intencja ginie drugi raz. A audyt i ewentualna naprawa są wyceniane osobno, żeby wynik audytu nie zależał od wielkości naprawy. Zakres audytu: - W zakresie: sześć miar powyżej policzonych na waszym repozytorium, ze skryptami zostawionymi u was, żeby zespół mógł je uruchamiać dalej - W zakresie: raport długu uszeregowany według kosztu zmiany, w którym każda pozycja nazywa moduł, mechanizm i miarę, która go ujawniła - W zakresie: plan naprawy z kolejnością prac, właścicielem każdej pozycji i definicją ukończenia wyrażoną pomiarem - W zakresie: procedura przekazania własności modułów bez opiekuna nazwanym osobom, z zastępcą i datą przeglądu - Poza zakresem: przepisywanie, refaktoryzacja albo migracja kodu; to osobny zakup, od 23Minds albo od kogokolwiek innego, a raport jest napisany tak, żeby dało się go przekazać jednym i drugim - Poza zakresem: infrastruktura, konfiguracja chmury i testy penetracyjne; audyt czyta repozytorium, a nie środowisko, w którym ono działa ### Gdzie to się psuje i co z tym robimy **Duplikacja zamiast ponownego użycia** Asystent pracuje na plikach ze swojego kontekstu. Gdy podobny pomocnik istnieje gdzie indziej w repozytorium, asystent o nim nie wie, więc pisze drugi albo dokłada gałąź do struktury, którą widzi. Po kilku miesiącach ta sama logika walidacji, ponowień albo mapowania żyje w czterech miejscach z drobnymi różnicami. Poprawka trafia do jednego z nich, a pozostałe trzy zachowują błąd. To dokładnie ta niespójna zmiana klonu, którą Juergens i współautorzy powiązali z potwierdzonymi błędami. Co z tym robimy: Uruchamiamy wykrywanie klonów w całym repozytorium (nie per pull request) i porównujemy każdą grupę klonów, żeby znaleźć kopie zmienione tylko w jednym miejscu. Każda niespójna grupa dostaje werdykt uzgodniony z zespołem: rozbieżność zamierzona albo poprawka, która ominęła rodzeństwo. Te na ścieżkach krytycznych trafiają na początek planu naprawy, a po naprawie przez zespół detektor uruchamiamy ponownie, żeby potwierdzić spójność grupy. Zespół zatrzymuje konfigurację detektora, więc następny raport jest porównywalny. Co zostaje u was: rejestr klonów z każdą niespójną grupą, jej werdyktem i priorytetem oraz konfiguracja detektora **Utracona intencja zmiany** Opis pull requesta jest generowany z diffu, więc wyjaśnia, co się zmieniło, a zwykle nie dlaczego. Prompt, który wyprodukował zmianę, nie jest nigdzie zapisany, a ticket mówi tylko, czego chciał użytkownik, a nie jaki kompromis przyjął inżynier. Pół roku później czytelnik widzi, że limit czasu ustawiono na jedenaście sekund. Nie ma jak się dowiedzieć, czy to była decyzja, czy wartość domyślna. Następna zmiana albo utrwala przypadek, albo psuje decyzję. Co z tym robimy: Bierzemy próbkę scalonych zmian z okresu po wdrożeniu asystentów i śledzimy każdą wstecz do ticketu, promptu albo zapisanej decyzji. Udział zmian, których nie da się prześledzić, to liczba, której zespół potrzebuje. Potem dodajemy do szablonu pull requesta konwencję zapisu zmiany, jedną linię intencji i ograniczenie, które spełnia, a po kwartale próbkujemy ponownie, żeby sprawdzić, czy udział się ruszył. Co zostaje u was: próbka śledzenia intencji z udziałem zmian nie do prześledzenia oraz poprawiony szablon pull requesta **Testy pisane pod implementację** Poproszony o testy asystent czyta kod, który właśnie napisał. Sprawdza to, co ten kod robi, razem z błędem. Pokrycie linii w module rośnie, dashboard robi się zielony, a testy przeszłyby tak samo, gdyby logika była błędna. Zespół uznaje moduł za chroniony przez testy. Przez to mniej dokładnie sprawdza późniejsze zmiany. Co z tym robimy: Zawężamy pytanie do ścieżek krytycznych i tam uruchamiamy testy mutacyjne: małe celowe błędy wstrzyknięte do kodu, potem zliczenie, ile z nich zestaw łapie. Testy, które nie łapią niczego, wypisujemy z nazwy. Te na ścieżkach krytycznych trafiają do planu naprawy z zaleceniem: przepisać z wymagania, a nie z kodu. Po naprawie przez zespół uruchamiamy mutacje ponownie, żeby sprawdzić, czy wynik się zmienił. Co zostaje u was: wynik mutacji na każdej ścieżce krytycznej, przed i po, z listą testów, które nie złapały żadnego mutanta **Zależności, których nikt nie wybrał** Pakiet pojawia się w pliku blokady, bo model widział go w danych treningowych wystarczająco często, żeby go zaproponować, a nie dlatego, że ktoś porównał go z tym, co repozytorium już miało, a potem zdecydował go utrzymywać. W efekcie są dwa klienty HTTP, trzy biblioteki do dat i narzędzie, które dubluje funkcję z biblioteki standardowej, każde z własnym rytmem aktualizacji i licencją. Gdy przychodzi informacja o podatności, nikt nie wie, kto odpowiada za decyzję, czy pakiet zostaje. Co z tym robimy: Porównujemy manifest zależności sprzed wdrożenia asystentów i po nim, a przy każdym dodanym pakiecie zapisujemy, czy pokrywa się z istniejącą zależnością, kiedy miał ostatnie wydanie i na jakiej jest licencji. Każda zależność dostaje właściciela i werdykt: zostaje, do zamiany, do usunięcia. Sprawdzamy, czy po usunięciach projekt się buduje i przechodzi testy, a log zostawiamy zespołowi, żeby następne dodanie było decyzją, a nie podpowiedzią. Co zostaje u was: log decyzji o zależnościach z właścicielem i werdyktem przy każdym pakiecie **Moduł bez właściciela** Z asystentem każdy inżynier może zmieniać każdy moduł i często to robi. Koncentracja własności spada, liczba autorów pojedynczych zmian na plik rośnie, a osobą, która mogłaby odpowiedzieć na pytanie o moduł, bywa nikt, bo ostatnie pięć zmian zrobiło pięć różnych osób, każda z narzędziem. Bird i współautorzy powiązali ten wzorzec z awariami na długo przed asystentami; asystenci tylko sprawiają, że taniej go wyprodukować. Co z tym robimy: Budujemy z gita mapę własności dla każdego modułu, liczymy udział głównego właściciela i liczbę autorów pojedynczych zmian i oznaczamy moduły, w których obie miary idą w złą stronę. Dla każdego oznaczonego modułu zespół wskazuje właściciela i zastępcę, a przekazanie jest spisaną procedurą z datą przeglądu. Po kwartale liczymy mapę ponownie, żeby sprawdzić, czy udziały się ruszyły. Co zostaje u was: mapa własności per moduł z nazwanym właścicielem i zastępcą oraz procedura przekazania ### Co dostajecie - Punkt odniesienia dla sześciu miar, ze skryptami i konfiguracją, żeby zespół mógł je uruchamiać dalej - Raport długu uszeregowany według kosztu zmiany; każda pozycja nazywa moduł, mechanizm i miarę, która go ujawniła - Plan naprawy z kolejnością prac, właścicielem każdej pozycji i definicją ukończenia wyrażoną pomiarem - Procedura przekazania własności modułów bez opiekuna, z właścicielem, zastępcą i datą przeglądu - Log decyzji o zależnościach z werdyktem dla każdego pakietu dodanego od wdrożenia asystentów - Spisana granica zakresu mówiąca, czego audyt nie objął, żeby raport dało się przekazać komukolwiek, kto zrobi przepisanie ### Jak pracujemy 1. **1. Punkt odniesienia z gita** (Tydzień 1): Z dostępem do odczytu liczymy zmienność, czas do pierwszej poprawki i własność dla każdego modułu i uzgadniamy z waszym zespołem, które ścieżki są krytyczne. Na tym etapie są tylko liczby i okres, który obejmują. 2. **2. Analiza statyczna, klony i mutacje** (Tydzień 1-2): Uruchamiamy wykrywanie klonów, śledzenie problemów w commitach autorstwa asystenta i testy mutacyjne na ścieżkach krytycznych. Każde ustalenie jest przypięte do modułu i miary. 3. **3. Raport i priorytety** (Tydzień 2-3): Szeregujemy ustalenia według kosztu zmiany i omawiamy je z ludźmi, którzy utrzymują kod. Gdy zespół nie zgadza się z kolejnością, niezgoda trafia do raportu razem z powodem. 4. **4. Przekazanie własności i ponowny pomiar** (Tydzień 3, potem jeden pomiar po kwartale): Przekazujemy plan, procedurę i skrypty, a po kwartale wracamy, żeby policzyć punkt odniesienia ponownie i opisać wyniki ponownego pomiaru: które miary się poprawiły, które nie i dlaczego. ### FAQ **Q: Czy kod pisany przez AI naprawdę jest droższy w utrzymaniu?** Opublikowane dowody tego nie rozstrzygają. Kontrolowany eksperyment ze 151 uczestnikami nie znalazł spójnych sygnałów pogorszenia utrzymywalności; badanie 302,6 tys. commitów autorstwa asystentów w prawdziwych repozytoriach znalazło, że 22,7% wprowadzonych przez nie problemów pozostawało w kodzie na koniec badanego okresu. Te badania nie rozstrzygają, z czego wynikają różnice między zespołami. Dlatego mierzymy wasze repozytorium, zamiast cytować wam którekolwiek z nich. **Q: Czy nasz zespół policzy te miary bez audytu?** Tak, i po to zostawiamy skrypty. Audyt dokłada ocenę priorytetów przez kogoś, kto nie zyskuje na wielkości naprawy, poprawnie ustawione za pierwszym razem przebiegi mutacji i klonów oraz raport, którego wasi inżynierowie nie musieli pisać o własnej pracy. **Q: Jaki poziom tych miar jest alarmujący?** Nie ma opublikowanego uniwersalnego progu. Porównanie, które się broni, to wasze własne repozytorium sprzed asystentów albo moduły pisane z nimi i bez nich w tym samym okresie. Alarmem jest miara idąca w złą stronę kwartał po kwartale. **Q: Czy refaktoryzujecie albo przepisujecie kod, który znajdziecie?** Nie. Audyt daje uszeregowany raport, plan naprawy i przekazanie własności. Przepisanie to osobna praca, którą wykonuje wasz zespół, 23Minds w osobnym zleceniu albo ktokolwiek inny, kogo wybierzecie, a raport jest napisany tak, żeby dało się go przekazać każdemu z nich. **Q: Jakiego dostępu potrzebujecie?** Dostępu do odczytu historii repozytorium, logów CI i manifestów zależności oraz możliwości uruchomienia analizy statycznej i testów mutacyjnych na kopii. Nie potrzebujemy dostępu do produkcji, a audyt nie dotyka infrastruktury. **Q: Ile to trwa?** Około trzech tygodni dla jednego repozytorium typowej wielkości, z jednym ponownym pomiarem po kwartale. Monorepo albo kilka serwisów trwa dłużej, a o ile, mówimy po pierwszym dniu pracy nad punktem odniesienia, nie wcześniej. **Q: Czy to obejmuje problemy bezpieczeństwa w wygenerowanym kodzie?** Analiza statyczna zgłasza problemy bezpieczeństwa obok złych wzorców w kodzie i trafiają one do raportu. Przegląd bezpieczeństwa kodu i jego zależności to osobna praktyka z własnym zakresem; raport odsyła do niej. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/pokrycie-testowe ### Źródła - Liu i in., Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild (arXiv:2603.28592, 2026): https://arxiv.org/abs/2603.28592 - Borg i in., Echoes of AI: Investigating the Downstream Effects of AI Assistants on Software Maintainability (arXiv:2507.00788, Empirical Software Engineering 2026): https://arxiv.org/abs/2507.00788 - Sawada i in., To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study (arXiv:2605.06464, 2026): https://arxiv.org/abs/2605.06464 - Ehsani i in., Faster Code, Deeper Debt? A Multivocal Literature Review on Technical Debt in LLM-Assisted Software Development (arXiv:2606.14796, 2026): https://arxiv.org/abs/2606.14796 - Google Cloud, Announcing the 2025 DORA Report: https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report - Bird i in., Don't Touch My Code! Examining the Effects of Ownership on Software Quality (ESEC/FSE 2011): https://www.microsoft.com/en-us/research/publication/dont-touch-my-code-examining-the-effects-of-ownership-on-software-quality/ - Nagappan i Ball, Use of Relative Code Churn Measures to Predict System Defect Density (ICSE 2005): https://www.microsoft.com/en-us/research/publication/use-of-relative-code-churn-measures-to-predict-system-defect-density/ - Juergens i in., Do Code Clones Matter? (ICSE 2009): https://teamscale.com/publications/2009-do-code-clones-matter.pdf --- ## Testy regresyjne przed podmianą modelu AI: przypadki z oczekiwanymi decyzjami, które blokują wdrożenie **URL:** https://23minds.com/pl/przewodniki/testy-regresyjne-przed-zmiana-modelu > Przed zmianą modelu sprawdzicie decyzje agenta, wywołania narzędzi i skutki działań na zapisanych przypadkach testowych. Zestaw testów regresyjnych do podmiany modelu to wersjonowany zbiór prawdziwych przypadków z oczekiwaną decyzją i tolerancją dla każdego z nich, uruchamiany przed każdą zmianą modelu, promptu albo narzędzia i po niej, z progiem, który blokuje wdrożenie. Pokazuje, w których sprawdzonych przypadkach nowy model podejmuje inne decyzje, niż uzgodniono, bo przy wycofaniu modelu albo przejściu na tańszy regresja dotyczy tego, co agent zrobił, a recenzent czytający przykładowe odpowiedzi jej nie zobaczy. ### Podsumowanie 23Minds buduje zestawy testów regresyjnych do podmiany modelu dla zespołów inżynierskich, które prowadzą agentów LLM na produkcji albo przygotowują pierwsze uruchomienie i muszą przejść na nowy model w terminie wycofania u dostawcy albo z własnej decyzji kosztowej. Zestaw zapisuje oczekiwaną decyzję i wywołania narzędzi dla każdego przypadku, uruchamia stary i nowy model na tych samych przypadkach i raportuje diff decyzji, wywołań narzędzi, kosztu i opóźnienia, z progiem uzgodnionym przed przebiegiem, który blokuje podmianę po jego przekroczeniu. Te same testy uruchamiają się przy każdej zmianie promptu i narzędzi oraz w stałym rytmie, bo opublikowane dowody pokazują agentów zmieniających zachowanie bez żadnej zmiany identyfikatora modelu. Klient zatrzymuje zbiór przypadków, raport diff dla każdej podmiany, uruchamiające go zadanie CI i spisaną procedurę na zapowiedzi wycofania ze ścieżką powrotu. ### Dla kogo to jest - CTO i wiceprezesi ds. inżynierii, którzy dostali zapowiedź wycofania modelu stojącego za funkcją produkcyjną i muszą przed tą datą wiedzieć, co zamiennik zrobi inaczej - Zespoły platformowe, które wywołują modele przez alias albo tag latest i widziały zmianę zachowania bez żadnego wdrożenia w swojej historii - Właściciele agentów, którzy rezerwują, anulują, zwracają pieniądze albo odmawiają w imieniu klienta, gdzie zmieniona decyzja to zmieniona transakcja - Zespoły, od których dział finansów chce przejścia na tańszy model, a które nie umieją powiedzieć, czego tańszy model przestanie robić ### Co zmienia podmiana modelu i dlaczego przykładowe odpowiedzi tego nie pokazują Agent na produkcji to pętla decyzji: czy wywołać narzędzie, które, z jakimi argumentami, czy zapytać użytkownika, czy odmówić, czy się zatrzymać. Tekst, który zwraca, jest ostatnim krokiem. Po podmianie recenzent czyta właśnie tekst, a tekst nowszego modelu zwykle czyta się lepiej: czyściej, pewniej, z lepszym formatowaniem. Regresja dotyczy decyzji. Dwa przykładowe scenariusze: po podmianie agent po cichu przestaje anulować zamówienia; model zastępczy, poproszony o sprawdzenie dostępności, sam rezerwuje spotkanie. W obu odpowiedzi wyglądają dobrze, a skutek w systemie jest błędny. Badania nad ewaluacją agentów doszły do tego samego miejsca. Yao i współautorzy (2024), autorzy tau-bench, oceniają agenta przez porównanie stanu bazy na końcu rozmowy z opisanym stanem docelowym i wprowadzili miarę pass^k, prawdopodobieństwo, że agent zaliczy wszystkie k z k powtórzeń zadania, bo pojedynczy przebieg ukrywa niespójność. Ich najlepszy agent w tamtym czasie zaliczał poniżej 50% zadań i miał pass^8 poniżej 25% w domenie handlu. Testy, które oceniają końcowy tekst według zasad oceny, mierzą złą warstwę. Musi sprawdzać decyzję i stan końcowy oraz uruchamiać każdy przypadek więcej niż raz. ### Dryf wyniku i dryf wykonania Dryfem nazywa się dwie różne rzeczy i potrzebują one różnych kontroli. Dryf wyniku to model dający inną decyzję na tym samym wejściu, bo model się zmienił: migracja po wycofaniu, podmiana na tańszy poziom, alias, który wskazuje teraz gdzie indziej. Dryf wykonania to ten sam identyfikator modelu dający inne zachowanie, bo zmieniło się coś za identyfikatorem. Chen, Zaharia i Zou (2023) zmierzyli zachowanie tej samej usługi GPT-4 w marcu i czerwcu 2023 i stwierdzili spadek skuteczności w rozpoznawaniu liczb pierwszych z 84% do 51%, z gorszym wykonywaniem instrukcji i większą liczbą błędów formatowania w generowanym kodzie. Własna dokumentacja OpenAI do parametru seed mówi, że determinizm jest zapewniany w miarę możliwości, a pole system_fingerprint, które reprezentuje konfigurację zaplecza, z jaką działa model, zmienia się, gdy dostawca aktualizuje konfigurację numeryczną infrastruktury serwującej model. Obejście stosowane przez praktyków to logowanie identyfikatora modelu i danych o konfiguracji zaplecza (fingerprint), jeśli API je udostępnia, oraz alarm przy zmianie. To dobra kontrola obserwowalności i jej miejsce jest w warstwie śledzenia, obok kosztu i opóźnienia na wywołanie. Zestaw testów regresyjnych to inny instrument. Log mówi tylko tyle, że coś się zmieniło, nic o tym, co agent robi teraz inaczej. Milczy też, gdy identyfikator jest bez zmian, a zachowanie i tak się przesuwa. Na to pytanie odpowiadają testy; zalogowany identyfikator mówi, kiedy uruchomić je poza cyklem wydań, a stały rytm uruchomień pokrywa zmiany bez żadnego sygnału. ### Jak trzej główni dostawcy wycofują modele Okresy wyprzedzenia i mechanika aliasów różnią się między dostawcami, a te różnice decydują, jak duża część migracji jest pod kontrolą zespołu. Tabela streszcza, co dokumentacja każdego dostawcy wskazana w źródłach podaje w dniu publikacji tej strony; konkretne daty się zmieniają i nie są tu powtarzane, a zakres każdej deklaracji trzeba sprawdzić u dostawcy przed migracją. | Dostawca | Stany w cyklu życia | Deklarowane wyprzedzenie przed wyłączeniem | Aliasy i przypinanie | | --- | --- | --- | --- | | Anthropic | Aktywny, legacy, deprecated (nadal działa, zamiennik wskazany), retired (żądania kończą się błędem) | Co najmniej 60 dni dla modeli udostępnionych publicznie; e-mail plus dokumentacja | Daty dotyczą platform prowadzonych przez Anthropic; Bedrock i Vertex mają własne harmonogramy. Niektóre parametry żądania są wycofywane w nowszych modelach i zwracają błąd, więc podmiana może zepsuć żądanie, a nie tylko zmienić jego zachowanie | | OpenAI | Legacy (bez aktualizacji), deprecated (wycofanie zapowiedziane), shut down (endpoint zniknął) | Co najmniej sześć miesięcy dla modeli ogólnie dostępnych, trzy miesiące dla wariantów specjalistycznych, nawet dwa tygodnie dla wersji podglądowych | Datowane migawki i aliasy wskazujące migawkę; przypięcie migawki ustala wersję, alias się przesuwa | | Google Gemini | Eksperymentalny, podglądowy, stabilny, deprecated, shut down; podane daty to najwcześniejsze możliwe | Wersje podglądowe wycofywane z co najmniej dwutygodniowym wyprzedzeniem; alias latest podmieniany przy każdym wydaniu, z dwutygodniowym powiadomieniem e-mail o zmianach niezgodnych wstecz | Wersje stabilne zwykle się nie zmieniają i są zalecane na produkcję; latest może wskazywać wersję podglądową albo eksperymentalną | ### Testy: przypadki, oczekiwane decyzje, tolerancja, próg Przypadek to zapisana prawdziwa interakcja: wejście, odpowiedzi narzędzi odtwarzane z nagrania, żeby środowisko się nie zmieniało, oczekiwana decyzja, oczekiwane wywołania narzędzi z istotnymi argumentami oraz stan końcowy. Przypadki pochodzą ze śladów produkcyjnych albo, przed pierwszym uruchomieniem, ze scenariuszy testowych, warstwowanych tak, żeby obecne były te rzadkie i kosztowne: odmowy, działania nieodwracalne, eskalacje do człowieka, przypadki brzegowe z poprzednich incydentów. Każdy przypadek ma tolerancję. Przypadek anulowania nie toleruje zmiany decyzji ani zmiany identyfikatora zamówienia przekazanego do narzędzia; przypadek streszczenia toleruje inne sformułowanie i sprawdza tylko, czy pojawiają się nazwane fakty. Kryteria tekstowe, które wymagają modelu oceniającego, dostają go, a ten sędzia potrzebuje własnej kalibracji wobec ocen ludzi, która jest tematem osobnego przewodnika na tej stronie i nie jest tu powtarzana. Próg jest zapisywany przed przebiegiem, dla każdej klasy przypadków, a nie po przeczytaniu diffu. Klasy z działaniami nieodwracalnymi dostają zerową tolerancję: każda decyzja niezgodna z oczekiwanym wynikiem blokuje wdrożenie. Klasy z odwracalnymi skutkami dostają udział przypadków, które mogą się zmienić, uzgodniony z właścicielem danego przepływu. Każdy przypadek uruchamia się kilka razy na każdym modelu, więc porównanie to pass^k wobec pass^k; raport porównuje skuteczność i powtarzalność obu modeli z uzgodnionymi progami, a przypadek niespójny na nowym modelu i spójny na starym liczy się jako regresja, bo agent działa w imieniu klienta. Kapoor i współautorzy (2024) argumentują, że ewaluacja agentów bez kosztu jest niepełna, a benchmarki bez zbiorów odłożonych ulegają przeuczeniu; testy raportują koszt i opóźnienie dla każdego przypadku obok diffu decyzji, a wycinek przypadków jest odłożony poza zasięg każdego, kto stroi prompt pod nowy model. - Wyzwalacze: zmiana modelu albo wersji, zmiana promptu, zmiana schematu albo opisu narzędzia, zmiana identyfikatora modelu albo konfiguracji zaplecza zalogowana na produkcji oraz stały rytm uruchomień niezależny od tych zdarzeń. - Diff dla każdego przypadku: oczekiwana wobec zaobserwowanej decyzji, wywołania narzędzi i argumenty, stan końcowy, tokeny i koszt, opóźnienie, spójność między powtórzeniami. - Bramka: próg dla każdej klasy przypadków uzgodniony na piśmie przed pierwszym przebiegiem; po jego przekroczeniu zadanie CI kończy się błędem i podmiana nie idzie dalej. - Pułapka pewności siebie: tekst nowego modelu jest ukryty przed recenzentami, dopóki nie przeczytają diffu decyzji, żeby pewniejszy ton nie został wzięty za lepszą decyzję. ### Procedura podmiany i ścieżka powrotu Zapowiedź wycofania uruchamia procedurę, która już istnieje. Zbiór przypadków jest zamrażany w dniu zapowiedzi i oznaczany identyfikatorem wersji starego modelu, a wyniki starego modelu na nim są zapisywane jako punkt odniesienia, dopóki stary model jeszcze odpowiada. Zamiennik uruchamia się na tym samym zamrożonym zbiorze; raport diff idzie do właściciela każdego przepływu z dołączonymi przypadkami, które nie przeszły. Zmiany promptu robione pod nowy model są wersjonowane osobno i przechodzą przez testy jeszcze raz, bo poprawka promptu dla jednej klasy przypadków często przesuwa inną. Podmiana wchodzi za przełącznikiem, który do dnia wycofania może wskazać z powrotem stary model, więc regresja znaleziona na produkcji ma powrót przez zmianę konfiguracji, bez hotfixa. Po dacie wycofania nie ma dokąd wrócić i to jest argument za rozpoczęciem w dniu zapowiedzi, a nie tydzień przed terminem. Procedura wskazuje też, kto obserwuje strony dostawców o wycofaniach i noty wydań, w jakim rytmie i gdzie trzymane są następne znane daty. Przy kolejnej migracji zespół korzysta z istniejących testów, progów i procedury. ### Gdzie to się psuje i co z tym robimy **Podmiana sprawdzona na jakości tekstu, a zmienia się decyzja** Zespół porównuje przykładowe odpowiedzi starego i nowego modelu, czyta nowe jako czystsze i lepiej ułożone, po czym wdraża. Przypadków, w których agent powinien był zapytać, odmówić albo się zatrzymać, nie ma w próbce, albo są, ale recenzent czyta prozę zamiast wywołania narzędzia. Anulowanie, które już nie następuje, albo spotkanie zarezerwowane zamiast sprawdzone, znajduje klient. Co z tym robimy: Zapisujemy oczekiwaną decyzję, wywołania narzędzi i stan końcowy dla każdego przypadku, a diff liczy się na tych polach, zanim ktokolwiek przeczyta tekst. Przypadki z klas z działaniami nieodwracalnymi są nadpróbkowane ze śladów produkcyjnych. Recenzent widzi najpierw diff decyzji, a tekst dopiero potem. Co zostaje u was: zbiór przypadków z oczekiwanymi decyzjami i wywołaniami narzędzi dla każdego przypadku oraz raport diffu decyzji dla każdej podmiany z dołączonymi przypadkami, które nie przeszły **Alias się przesunął, a nikt niczego nie wdrożył** Aplikacja wywołuje model przez alias albo tag latest. Dostawca kieruje alias na nowe wydanie, w deklarowanym okresie wyprzedzenia albo, przy zmianach konfiguracji zaplecza, bez żadnego wyprzedzenia. Zachowanie zmienia się w dniu bez wdrożenia w historii zespołu, a dochodzenie zaczyna się w kodzie aplikacji. Chen, Zaharia i Zou (2023) udokumentowali, jak zachowanie tego samego endpointu przesunęło się znacząco w ciągu trzech miesięcy. Co z tym robimy: Przypinamy model do stałej wersji tam, gdzie dostawca ją oferuje, logujemy do warstwy śledzenia identyfikator modelu i dane o konfiguracji zaplecza (jeśli API je zwraca) i dodajemy alarm przy zmianie. Zmieniony identyfikator uruchamia przebieg testów poza cyklem wydań, więc zespół widzi diff decyzji zaraz po przebiegu, a nie objaw kilka tygodni później. Co zostaje u was: przypięta wersja w konfiguracji, pola identyfikatora i konfiguracji zaplecza w każdym śladzie oraz alarm podpięty pod zaplanowany przebieg testów **Nowszy model brzmi pewniej, więc jest czytany jako lepszy** Jeden inżynier przepuszcza garść promptów przez oba modele i woli nowy, bo mniej się asekuruje i lepiej formatuje. Pewność siebie w tekście zostaje wzięta za dowód lepszej decyzji. W przypadku opisywanym przez praktyków pewniejszy model poszedł o krok dalej niż proszono i zarezerwował spotkanie; ton był powodem, dla którego nikt tego nie zakwestionował. Co z tym robimy: Liczymy wskaźnik zaliczeń na poziomie decyzji i spójność między powtórzeniami dla każdej klasy przypadków, z tekstem ukrytym, dopóki diff nie zostanie przeczytany. Tam, gdzie nowy model działa poza tym, o co prosił przypadek, przypadek nie przechodzi niezależnie od tego, jak czyta się odpowiedź, a ustalenie trafia do pracy nad promptem dla nowego modelu z dołączonym przypadkiem. Co zostaje u was: wskaźnik zaliczeń i pass^k dla każdej klasy dla obu modeli na tym samym zamrożonym zbiorze, przejrzane przed jakimkolwiek tekstem odpowiedzi **Próg ustalony po poznaniu wyniku** Testy się uruchamiają, nowy model zalicza 92% przypadków, a na tym samym spotkaniu 90% zostaje uznane za akceptowalne. W tych 8% są dwa przypadki odmowy i jeden zwrot pieniędzy, których nikt nie ogląda z osobna, bo wynik łączny przeszedł. Próg ustalony po wyniku niczego nie blokuje. Co z tym robimy: Próg dla każdej klasy przypadków zapisujemy z właścicielem każdego przepływu przed pierwszym przebiegiem, a klasy z działaniami nieodwracalnymi dostają zerową tolerancję. Zadanie CI nie przechodzi przy każdej klasie ponad jej progiem i wypisuje przypadki, które nie przeszły, według klas, więc przypadek zwrotu nie schowa się za setką zaliczonych streszczeń. Co zostaje u was: rejestr progów dla każdej klasy przypadków z właścicielem i datą oraz zadanie CI, które kończy się błędem po ich przekroczeniu **Testy uruchamiają się tylko przy zmianach modelu, a edycja narzędzia przechodzi bokiem** Programista zmienia kolejność listy narzędzi, nazwę parametru albo opis narzędzia w ramach niezwiązanego zgłoszenia. Wybór narzędzia przez model zależy od tych opisów, więc agent zaczyna wybierać inne narzędzie na tym samym wejściu. Model się nie zmienił, więc testy nie zostały uruchomione, a regresja zostaje przypisana modelowi przy następnej podmianie. Co z tym robimy: Liczymy jeden skrót z wersji modelu, promptu i schematów narzędzi razem i uruchamiamy testy, gdy zmieni się którekolwiek z trzech, w tym samym zadaniu CI. Raport diff mówi, które z trzech zmieniło się od punktu odniesienia, więc przyczyna jest w raporcie, a nie w bisekcji. Co zostaje u was: łączny skrót modelu, promptu i narzędzi zapisany przy każdym przebiegu testów oraz wyzwalacz CI na każde z nich ### Co dostajecie - Zbiór przypadków: prawdziwe interakcje ze śladów produkcyjnych z odtwarzanymi nagraniami narzędzi, oczekiwaną decyzją, oczekiwanymi wywołaniami narzędzi i argumentami, oczekiwanym stanem końcowym i tolerancją dla każdego przypadku, warstwowany według klas i wersjonowany ze skrótem modelu, promptu i narzędzi - Rejestr progów: jeden wiersz na klasę przypadków z tolerancją, właścicielem i datą uzgodnienia, wpięty w zadanie CI jako bramka blokująca - Raport diff dla każdej podmiany: różnice decyzji, wywołań narzędzi, stanu końcowego, kosztu i opóźnienia między punktem odniesienia a kandydatem, pass^k dla każdej klasy, dołączone przypadki, które nie przeszły, tekst odpowiedzi ukryty do przeczytania diffu - Zadanie CI, które uruchamia testy przy zmianie modelu, promptu albo narzędzi, przy zmianie identyfikatora zalogowanej na produkcji oraz w stałym rytmie, z łącznym skrótem zapisanym dla każdego przebiegu - Pola śledzenia dla identyfikatora modelu i danych o konfiguracji zaplecza, jeśli API je udostępnia, z alarmem przy zmianie i zaplanowanym przebiegiem testów za nim - Procedura na wycofanie: kto obserwuje które strony dostawców i w jakim rytmie, kroki zamrożenia i punktu odniesienia w dniu zapowiedzi, przełącznik wskazujący z powrotem stary model do dnia jego wycofania oraz ścieżka powrotu ### Jak pracujemy 1. **1. Klasy przypadków i rejestr progów** (Tydzień 1): Mapujemy z wami decyzje i narzędzia agenta, nazywamy klasy przypadków i zapisujemy tolerancję oraz właściciela dla każdej klasy przed jakimkolwiek przebiegiem. Działania nieodwracalne, odmowy i eskalacje dostają własne klasy z zerową tolerancją. To dokument, który bramka będzie egzekwować. 2. **2. Zbiór przypadków ze śladów produkcyjnych** (Tydzień 1-3): Pobieramy prawdziwe interakcje z waszych śladów albo, przed pierwszym uruchomieniem, scenariusze testowe, warstwowane według klas, nagrywamy odpowiedzi narzędzi dla identycznego odtworzenia środowiska i oznaczamy oczekiwaną decyzję, wywołania narzędzi i stan końcowy dla każdego przypadku razem z właścicielami przepływów. Wycinek odłożony trzymamy poza zasięgiem każdego, kto stroi prompty. 3. **3. Punkt odniesienia i pierwszy diff** (Tydzień 3-4): Uruchamiamy obecny model kilka razy na każdym przypadku, żeby zapisać punkt odniesienia i pass^k dla każdej klasy, a potem model kandydujący na tym samym zamrożonym zbiorze. Pierwszy raport diff idzie do właścicieli przepływów z przypadkami, które nie przeszły, oraz kosztem i opóźnieniem dla każdej klasy. 4. **4. Wpięcie w CI i wykrywanie zmian w działającym systemie** (Tydzień 4-5): Dodajemy testy jako zadanie CI wyzwalane łącznym skrótem modelu, promptu i narzędzi oraz stałym rytmem, dodajemy pola identyfikatora i konfiguracji zaplecza do waszych śladów z alarmem i zaplanowanym przebiegiem za nim oraz umieszczamy w konfiguracji przełącznik modelu ze ścieżką powrotu. 5. **5. Procedura na wycofanie i przekazanie** (Tydzień 5-6, zależnie od liczby przepływów): Piszemy procedurę z waszym zespołem: kto obserwuje strony dostawców, co się dzieje w dniu zapowiedzi i jak podmiana wchodzi i wraca. Przeprowadzamy z wami jedną podmianę od początku do końca na testach i zostawiamy zbiór przypadków, rejestr i format raportu w waszym repozytorium. ### FAQ **Q: Przypinamy model do stałej wersji. Czy nadal potrzebujemy testów?** Przypięcie usuwa problem aliasu i zostawia problem wycofania, bo przypięta wersja też dostaje datę wycofania i potem przestaje odpowiadać. Testy mówią, co zamiennik robi inaczej na waszych przypadkach, zanim ta data nadejdzie. Przypięcie nie obejmuje też zmian konfiguracji zaplecza za tym samym identyfikatorem, dlatego zwracany identyfikator i dane o konfiguracji, jeśli API je udostępnia, trafiają do waszych śladów obok przypięcia, a testy uruchamiają się także w stałym rytmie. **Q: Ilu przypadków potrzebuje zbiór?** Tylu dla każdej klasy przypadków, żeby próg na tej klasie miał sens, z nadpróbkowaniem klas nieodwracalnych, bo są rzadkie w ruchu i kosztowne, gdy pójdą źle. Nie ma liczby uniwersalnej; wielkość ustala się dla każdej klasy w kroku 1 na podstawie tego, ile kosztuje was zmieniona decyzja w tej klasie. Zbiór rośnie po każdym incydencie, bo incydent to przypadek, którego w zbiorze brakowało. **Q: Czy do oceny przypadków możemy użyć sędziego LLM?** Dla decyzji, wywołań narzędzi i stanu końcowego sędzia nie jest potrzebny: to porównanie wartości. Sędzia jest potrzebny do kryteriów tekstowych (na przykład czy streszczenie zawiera nazwane fakty) i musi być skalibrowany wobec waszych własnych oceniających oraz przypięty do wersji, inaczej podmiana sędziego pokaże się jako podmiana produktu. Tę kalibrację opisujemy w osobnym przewodniku i tu z niej korzystamy, zamiast budować ją od nowa. **Q: Dostawca dał nam 60 dni. Czy to wystarczy?** Zwykle wystarcza zespołowi, który ma zbiór przypadków i zadanie CI, bo migracja to wtedy przebieg, przegląd diffu i praca nad promptem dla klas, które nie przeszły; czas zależy od liczby przepływów i poprawek. Jest ciasno dla zespołu, który zaczyna od zera, dlatego pierwsze zlecenie buduje testy na obecnym modelu, zanim przyjdzie jakakolwiek zapowiedź. Potem okres wyprzedzenia idzie na diff, a nie na budowę instrumentu. **Q: Tańszy model nie zalicza 6% przypadków. Podmieniać czy nie?** To zależy od tego, w których klasach siedzi te 6%. Dlatego próg jest dla każdej klasy osobno. Sześć procent w streszczeniach, którym brakuje jednego z nazwanych faktów, to podmiana z korektą promptu. Sześć procent, w których jest jeden zwrot pieniędzy albo jedna odmowa, blokuje podmianę do czasu, aż te przypadki przejdą, niezależnie od oszczędności. Raport wypisuje przypadki, które nie przeszły, według klas, więc decyzja zapada na przypadkach, a kolumny kosztu i opóźnienia pokazują, jakie oszczędności daje zmiana modelu. **Q: Co robić, gdy testy nie przechodzą po zmianie, której nie zrobiliśmy?** To przypadek dryfu wykonania: zalogowany identyfikator albo konfiguracja zaplecza się zmieniły, albo żadne się nie zmieniło, a zachowanie i tak się przesunęło. Przebieg wyzwolony alarmem albo stałym rytmem daje diff decyzji. Dalej opcje są takie same jak przy planowanej podmianie: praca nad promptem dla klas, które nie przeszły, przypięta wersja, jeśli dostawca ją oferuje, albo przejście na model zastępczy z testami jako bramką. **Q: Czy to obejmuje zmiany promptu i narzędzi, które robimy sami?** Tak. Po pierwszej podmianie testy uruchamiają się głównie przy takich zmianach, bo zdarzają się częściej niż podmiany modelu. Zadanie CI wyzwala się łącznym skrótem modelu, promptu i schematów narzędzi, a raport mówi, które z trzech się zmieniło. Zmieniona nazwa parametru narzędzia może przesunąć decyzje tak samo jak podmiana modelu, a wyzwalacz tylko na zmiany modelu nigdy by się dla niej nie uruchomił. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/ewaluacja-jakosci-ai ### Źródła - Anthropic, Model deprecations: stany w cyklu życia, co najmniej 60 dni wyprzedzenia dla modeli udostępnionych publicznie, platformy partnerskie z własnymi harmonogramami, wycofane parametry żądania zwracające błąd w nowszych modelach: https://platform.claude.com/docs/en/about-claude/model-deprecations - OpenAI, Deprecations: rozróżnienie deprecation i shutdown, wyprzedzenie co najmniej sześciu miesięcy dla modeli ogólnie dostępnych, trzech dla wariantów specjalistycznych i nawet dwóch tygodni dla preview, datowane snapshoty i aliasy: https://developers.openai.com/api/docs/deprecations - Google, Gemini API model deprecations: podane daty wyłączenia to najwcześniejsze możliwe, zamiennik wskazany przy każdym wycofaniu: https://ai.google.dev/gemini-api/docs/deprecations - Google, Gemini models: wzorce nazw wersji, wersje stabilne zwykle się nie zmieniają, alias latest podmieniany przy każdym wydaniu z dwutygodniowym powiadomieniem e-mail przy zmianach niekompatybilnych, preview wycofywane z co najmniej dwutygodniowym wyprzedzeniem: https://ai.google.dev/gemini-api/docs/models - OpenAI Cookbook, Reproducible outputs with the seed parameter: determinizm w miarę możliwości i system_fingerprint jako konfiguracja zaplecza, na którym działa model: https://developers.openai.com/cookbook/examples/reproducible_outputs_with_the_seed_parameter - Chen, Zaharia i Zou (2023), How is ChatGPT's behavior changing over time?: ten sam endpoint w marcu i czerwcu 2023, rozpoznawanie liczb pierwszych z 84% do 51%, gorsze wykonywanie instrukcji i formatowanie kodu: https://arxiv.org/abs/2307.09009 - Yao i in. (2024), tau-bench: A Benchmark for Tool-Agent-User Interaction: ewaluacja przez porównanie stanu końcowego bazy ze stanem docelowym, miara stabilności pass^k, najlepszy agent poniżej 50% zaliczeń i pass^8 poniżej 25% w domenie detalicznej: https://arxiv.org/abs/2406.12045 - Kapoor i in. (2024), AI Agents That Matter: koszt jako miara obok trafności, zbiory odłożone przeciw przeuczaniu na benchmarku, powtarzalność ewaluacji agentów: https://arxiv.org/abs/2407.01502 --- # Szkolenia, wdrożenia i nadzór (anchor 01) **URL:** https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai **Highlight:** Wybrane programy z dofinansowaniem BUR > Szkolenia z AI dla zespołów inżynierskich i biznesowych, zasady korzystania z AI w firmie i techniczne przygotowanie do wymagań AI Act. Wybrane programy z możliwością dofinansowania z BUR. ### Podsumowanie Instytut AI, obszar szkoleń 23Minds, prowadzi szkolenia z kodowania z AI, automatyzacji pracy i bezpiecznego korzystania z narzędzi AI. Programy opracowują i prowadzą inżynierowie, którzy budują oprogramowanie z AI i audytują kod pisany przez AI. Ścieżki: inżynierska na narzędziach do kodowania z AI, biznesowa z automatyzacji i bezpiecznego użycia AI na co dzień, zarządcza z planu wdrożenia i mierzenia zwrotu. Podstawy nadzoru nad AI to cztery dokumenty: polityka użycia AI, lista dopuszczonych narzędzi, harmonogram ocen i wpisy do rejestru ryzyk; kryteria odbioru ustalane są z działem prawnym i zakupami. Techniczne przygotowanie do wymagań AI Act obejmuje inwentaryzację systemów, klasyfikację ryzyka i dokumentację techniczną, a zakres zależy od systemu i roli firmy. Art. 4 AI Act o kompetencjach w zakresie AI stosuje się od 2.02.2025, a obowiązki dla systemów wysokiego ryzyka z załącznika III od 2.12.2027. Wybrane programy szkoleniowe kwalifikują się do dofinansowania z Bazy Usług Rozwojowych (BUR), według zasad operatora. Szkolenia IT i doradztwo są w zakresie certyfikatu ISO 9001:2015 firmy (DNV, nr 10000439701-MSC-RvA-POL, ważny do 3.03.2027). ### Dla kogo to jest - Szefowie inżynierii, którzy wdrażają asystentów kodowania z AI w kilku zespołach naraz - HR i osoby odpowiedzialne za rozwój, które kupują praktyczne szkolenie z AI z dofinansowaniem z BUR - Szefowie operacji, którzy chcą ustalić zasady korzystania z AI w zespole - Właściciele firm, którzy szukają szkolenia z AI dla swojego zespołu i chcą wiedzieć, co po nim zostanie ### Problemy, które rozwiązujemy - Zespoły używają narzędzi AI każdy po swojemu, bez wspólnych zasad i bez oceny efektów - Zakupy i dział prawny blokują wdrożenie AI, bo nie ma żadnej polityki ani listy dopuszczonych narzędzi - Budżet szkoleniowy jest, ale trudno ocenić, czy po szkoleniu zespół używa AI w codziennej pracy - Licencje na narzędzia są kupione, a adopcja zatrzymała się na kilku entuzjastach ### Praktyki pod tym anchorem - Programy szkoleń AI - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/szkolenia-ai-z-dofinansowaniem - Zasady korzystania z AI w firmie - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zasady-korzystania-z-ai - Zgodność z AI Act po stronie technicznej - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zgodnosc-z-ai-act ### FAQ **Q: Czy szkolenie może być dofinansowane?** Wybrane szkolenia z AI kwalifikują się do dofinansowania z Bazy Usług Rozwojowych (BUR), zależnie od wielkości firmy, województwa i aktualnych zasad operatora. Sprawdzamy to z wami na rozmowie wstępnej, zanim cokolwiek zaplanujecie. **Q: Szkolicie programistów czy użytkowników biznesowych?** Jednych i drugich. Ścieżka inżynierska dotyczy pracy z asystentami kodowania, oceny kodu pisanego przez AI oraz zabezpieczeń: sekretów, uprawnień, przeglądu kodu. Ścieżka biznesowa dotyczy automatyzacji pracy, projektowania promptów i bezpiecznego użycia narzędzi AI na co dzień. Ścieżka dla kadry zarządzającej dotyczy planu wdrożenia i mierzenia zwrotu. **Q: Jaki nadzór nad AI wprowadzacie?** Ustalamy zasady użycia AI, listę dopuszczonych narzędzi, harmonogram oceny wyników trafiających do klientów oraz wpisy do rejestru ryzyk. Tyle, ile dział prawny i bezpieczeństwa potrzebują do odbioru. Nic ponad to. **Q: Ile trwa typowe zlecenie?** Warsztat dla zespołu do 12 osób albo wykład online bez limitu osób rozliczamy za dzień, a liczbę dni dobieramy do zespołu. Program dla stałej grupy (kohorta) trwa od 4 do 6 tygodni, z cotygodniowymi sesjami. Przygotowanie zasad korzystania z AI trwa do 3 tygodni, a analiza luk względem wymagań AI Act do 4 tygodni, licząc od zatwierdzenia zakresu. **Q: Jakie efekty mierzycie?** Udział osób w zespole używających narzędzi po szkoleniu, zaoszczędzony czas na osobę w tygodniu, udział zmian w kodzie przygotowanych z pomocą AI oraz wynik kontroli zgodności z zasadami. Konkretne wskaźniki uzgadniamy na rozmowie wstępnej. Samo korzystanie z narzędzi niewiele mówi: w raporcie DORA 2025 z AI w pracy korzystało 90% respondentów, a 30% miało niewielkie albo żadne zaufanie do jakości wyników narzędzi AI. **Q: Które terminy AI Act dotyczą naszej firmy?** Terminy zależą od roli firmy i klasyfikacji jej systemów AI, a interpretację prawną skonsultujcie z radcą albo kancelarią. Art. 4 (kompetencje w zakresie AI) i zakazy z art. 5 stosuje się od 2.02.2025, obowiązki dla modeli AI ogólnego przeznaczenia od 2.08.2025, a obowiązki przejrzystości z art. 50 od 2.08.2026. Rozporządzenie (UE) 2026/1744 zmieniło brzmienie art. 4 od 27.07.2026 i przesunęło obowiązki dla systemów wysokiego ryzyka na 2.12.2027 dla załącznika III i na 2.08.2028 dla AI w produktach regulowanych. W Polsce ustawa z 3 lipca 2026 r. o systemach sztucznej inteligencji (Dz.U. 2026 poz. 1003) obowiązuje od 11.08.2026, a przepisy o opiniach indywidualnych, kontroli i karach stosuje się od 28.10.2026. --- ## Programy szkoleń AI - Szkolenia i wdrożenia **URL:** https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/szkolenia-ai-z-dofinansowaniem **Service type:** Szkolenia z AI **Anchor:** Szkolenia, wdrożenia i nadzór (Szkolenia i wdrożenia) > Instytut AI prowadzi warsztaty i programy szkoleń z AI dopasowane do roli: dla inżynierii, produktu, operacji i kadry zarządzającej. Dzień szkolenia ma stałą cenę: warsztat dla zespołu do 12 osób albo wykład online bez limitu osób; program dla stałej grupy trwa od czterech do sześciu tygodni. ### Podsumowanie Instytut AI prowadzi programy szkoleń z AI opracowane przez inżynierów, którzy budują oprogramowanie z AI i audytują kod pisany przez AI. Ścieżka inżynierska obejmuje pracę z asystentami kodowania (Claude Code, Cursor, Copilot, Aider), ocenę kodu pisanego przez AI oraz zabezpieczenia: sekrety, uprawnienia, przegląd kodu. Ścieżka biznesowa obejmuje projektowanie promptów, automatyzację pracy i bezpieczne użycie narzędzi AI na co dzień. Ścieżka dla kadry zarządzającej obejmuje plan wdrożenia i mierzenie zwrotu. Dzień szkolenia ma stałą cenę: warsztat dla zespołu do 12 osób albo wykład online bez limitu osób; program dla stałej grupy (kohorta) trwa od czterech do sześciu tygodni i jest wyceniany jako projekt. Wybrane programy kwalifikują się do dofinansowania z BUR albo KFS, według zasad operatora. Obowiązek kompetencji w zakresie AI z art. 4 AI Act stosuje się od 2.02.2025. ### Dla kogo to jest - Menedżerowie inżynierii, którzy wdrażają asystentów kodowania z AI w swoich zespołach - Szefowie HR i rozwoju, którzy kupują praktyczne szkolenie z AI na zasadach dofinansowania z BUR - Projektanci produktu i product managerowie, którzy chcą pracować z AI sprawniej na co dzień - Zarządy, które budują kompetencje AI w całej firmie ### Problemy, które rozwiązujemy - Ogólne szkolenie od dostawcy narzędzia nie przekłada się na wasz kod ani wasze procesy - Inżynierowie używają narzędzi AI, ale nie umieją powiedzieć kolegom, jak wygląda dobra praca z nimi - Budżet szkoleniowy jest, ale trudno sprawdzić, czy trenerzy sami wdrażali to, czego uczą - Nie wiadomo, czy przy tej wielkości zespołu wybrać warsztat, czy program na kilka tygodni ### Co dostajecie - Program dopasowany do roli, waszej technologii, narzędzi i przypadków użycia - Warsztat na żywo, u was w biurze albo zdalnie - Ćwiczenia praktyczne na waszym kodzie albo waszych procesach - Pisemny podręcznik dla każdej ścieżki, a w programach kilkutygodniowych także nagrania sesji - Spotkanie kontrolne po 4-6 tygodniach z pomiarem, ile z tego weszło do codziennej pracy (w programach kilkutygodniowych; przy dniu warsztatowym jako opcja) ### Jak pracujemy 1. **1. Rozmowa o zakresie** (Tydzień 0): Potwierdzamy grupę, obecne użycie narzędzi AI, cele biznesowe i możliwość dofinansowania. 2. **2. Projekt programu** (Tydzień 1-2): Układamy agendę, wybieramy narzędzia do omówienia, przygotowujemy ćwiczenia na waszym kodzie albo procesach. 3. **3. Szkolenie** (Dni warsztatu według potrzeb zespołu albo 4-6 tygodni (program)): Prowadzimy warsztat albo program dla stałej grupy: ćwiczenia praktyczne, pytania, sesje robocze na prawdziwych problemach z waszej firmy. 4. **4. Spotkanie kontrolne** (4-6 tygodni po szkoleniu): Mierzymy użycie narzędzi po szkoleniu, nazywamy blokady i proponujemy następny krok. ### FAQ **Q: Czym różni się warsztat od programu dla stałej grupy?** Warsztat to intensywny program liczony w dniach, z ceną za dzień; najlepszy, gdy chcecie szybko zacząć korzystać z AI. Program dla stałej grupy (kohorta) to cztery do sześciu tygodni z cotygodniowymi sesjami i zadaniami między nimi; najlepszy, gdy chcecie zmienić codzienne nawyki w większym zespole. **Q: Czy szkolenie może iść na naszym prawdziwym kodzie?** Tak. Ćwiczenia budujemy na waszych repozytoriach, pod NDA. Inżynierowie uczą się wzorców pracy z AI na kodzie, nad którym będą pracować następnego dnia. **Q: Czy jest dofinansowanie z BUR?** Wybrane programy kwalifikują się do dofinansowania z Bazy Usług Rozwojowych, a w części firm także z Krajowego Funduszu Szkoleniowego. Wysokość zależy od wielkości firmy, województwa i aktualnych zasad operatora. Sprawdzamy to z wami na rozmowie wstępnej. Priorytety KFS na 2026 rok, ogłoszone przez ministra pracy 25.09.2025, wymieniają AI w priorytecie dotyczącym nowych procesów, technologii i narzędzi pracy. **Q: Jakie narzędzia omawiacie?** Narzędzia: asystenci kodowania Claude Code, Cursor, Copilot, Aider i Windsurf w ścieżce inżynierskiej; n8n, Zapier i własne agenty w ścieżce biznesowej. Tematy: praca z asystentem na prawdziwym kodzie, ocena wygenerowanych zmian, projektowanie promptów, automatyzacja powtarzalnych zadań. **Q: Jak mierzycie, czy szkolenie zadziałało?** W ścieżce inżynierskiej: udział zmian w kodzie przygotowanych z pomocą AI i kontrola jakości tych zmian na spotkaniu po szkoleniu. W ścieżkach biznesowych: czas wykonania wybranego zadania przed szkoleniem i po nim. W obu: ankieta przed i po, z rozdzieleniem deklaracji od zmierzonych danych. Wynik dostajecie w raporcie ze spotkania kontrolnego. Konkretne wskaźniki ustalamy na rozmowie o zakresie. **Q: Po co szkolić zespół, który już korzysta z narzędzi AI?** W ankiecie Stack Overflow 2025 z narzędzi AI korzystało albo planowało korzystać 84% programistów, którzy odpowiedzieli na to pytanie. Wśród odpowiadających na pytanie o zaufanie 46% nie ufało dokładności wyników, a wśród odpowiadających na pytanie o frustracje 66% wskazało odpowiedzi prawie dobre, ale nie do końca. W raporcie DORA 2025 z AI w pracy korzystało 90% respondentów, a 30% miało niewielkie albo żadne zaufanie do jakości wyników narzędzi AI. Ścieżka inżynierska obejmuje przegląd zmian wygenerowanych przez AI, testy wykrywające błędne działanie oraz ochronę sekretów i zarządzanie uprawnieniami. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai --- ## Zasady korzystania z AI w firmie - Szkolenia i wdrożenia **URL:** https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zasady-korzystania-z-ai **Service type:** Doradztwo w zakresie nadzoru nad AI **Anchor:** Szkolenia, wdrożenia i nadzór (Szkolenia i wdrożenia) > 23Minds opracowuje zasady korzystania z AI w firmie: dozwolone zastosowania i narzędzia, ochronę danych, odpowiedzialność za decyzje i kontrolę ryzyk. Tyle, ile dział prawny i bezpieczeństwa potrzebują, żeby podjąć decyzję o wdrożeniu. ### Podsumowanie 23Minds przygotowuje zasady korzystania z AI dla firm, które wdrażają AI wewnątrz organizacji. Pakiet obejmuje jedną organizację i kończy się czterema dokumentami oraz skrótem dla menedżerów. Dokumenty to: polityka użycia AI dopasowana do branży, lista dopuszczonych narzędzi z zasadami postępowania z danymi i kryteriami zatwierdzania kolejnych, harmonogram oceny wyników AI trafiających do klientów albo na produkcję oraz wpisy do rejestru ryzyk. Zestaw jest celowo mały: najmniejszy komplet, który pozwala działowi prawnemu i bezpieczeństwa podjąć decyzję o wdrożeniu. Usługi doradcze kwalifikują się do dofinansowania z BUR albo KFS według zasad operatora. ### Dla kogo to jest - Szefowie działów prawnych i zgodności, których poproszono o zgodę na wdrożenie AI - CISO, których zespoły inżynierskie chcą kupić licencje na asystentów kodowania z AI - Dyrektorzy operacyjni, którzy wprowadzają AI w działach poza inżynierią - Instytucje publiczne i firmy regulowane, które potrzebują zasad, jakie da się obronić przed audytorem ### Problemy, które rozwiązujemy - Inżynieria chce używać narzędzi AI, a dział prawny nie ma precedensu, na którym mógłby oprzeć zgodę - Każdy zespół pisze własne zasady użycia AI; są niespójne i nikt ich nie egzekwuje - Rejestr ryzyk nie ma wpisów o AI i audytor wskazał tę lukę - Ocena wyników AI jest nieformalna; nikt nie umie udowodnić jakości w czasie audytu ### Co dostajecie - Polityka użycia AI: jeden dokument, obejmuje pracowników i współpracowników - Lista dopuszczonych narzędzi z zasadami postępowania z danymi dla każdego narzędzia oraz kryteriami zatwierdzania kolejnych - Harmonogram ocen: które wyniki AI są sprawdzane, jak, przez kogo i jak często - Wpisy do rejestru ryzyk dotyczące użycia AI, dopasowane do waszego rejestru albo założone w nowym arkuszu - Jednostronicowa ściąga dla menedżerów do codziennego użytku ### Jak pracujemy 1. **1. Rozpoznanie branży i ryzyk** (Tydzień 1): Rozmawiamy z osobami odpowiedzialnymi za prawo, zgodność i inżynierię. Poznajemy wasz sposób zarządzania ryzykiem i ograniczenia branżowe. Wynik: lista zastosowań AI w firmie i ryzyk przy każdym z nich. 2. **2. Projekty dokumentów** (Tydzień 1-2): Piszemy politykę użycia AI, listę dopuszczonych narzędzi, harmonogram ocen i wpisy do rejestru ryzyk. Wynik: komplet projektów do przeglądu. 3. **3. Omówienie z osobami zatwierdzającymi** (Tydzień 2-3): Omawiamy projekty z działem prawnym, zgodności, bezpieczeństwa i inżynierią. Nanosimy uwagi. Wynik: zestaw uwag i zatwierdzona wersja dokumentów. 4. **4. Publikacja i szkolenie menedżerów** (Tydzień 3): Szkolimy menedżerów z codziennego stosowania zasad i publikujemy dokumenty wewnątrz firmy. Wynik: opublikowane dokumenty i skrót dla menedżerów. ### FAQ **Q: Czy to pełny system zarządzania ryzykiem AI, jak NIST AI RMF?** Nie. To minimum wystarczające, żeby odblokować użycie AI i przejść standardowe audyty. Firmy z dojrzałym programem zarządzania ryzykiem mogą później dołożyć NIST AI RMF, ISO/IEC 42001 albo podobny standard. Możemy to zaplanować jako kolejny krok. **Q: Czy polityka uwzględni zasady naszej branży?** Tak. Dopasowujemy dokumenty do branży: finanse (wytyczne KNF, MiFID, DORA), ochrona zdrowia (RODO, dane medyczne), sektor publiczny, technologie regulowane. Nie jesteśmy prawnikami; piszemy dokumenty, które wasz dział prawny może zatwierdzić. **Q: Czym to się różni od kupienia gotowego szablonu polityki AI?** Szablon jest pisany dla przypadku ogólnego i pomija pytania, które zadają wasi klienci w ocenie dostawców. My dopasowujemy dokumenty do waszych narzędzi, branży i tych pytań. Wynik da się obronić przy audycie. **Q: Czy wdrożycie też narzędzia do oceny, a nie tylko napiszecie politykę?** Tak. Harmonogram ocen można połączyć z wdrożeniem narzędzi w ramach LLM Observability (procesy ewaluacji, automatyczna ocena) albo z cyklicznym audytem w ramach praktyki Audyt kodu pisanego przez AI. **Q: Ile czasu mija do podpisanych dokumentów?** Projekty dokumentów powstają w trzy tygodnie od zatwierdzenia zakresu. Do opublikowanych, podpisanych dokumentów mija zwykle 4-6 tygodni od startu. Termin publikacji zależy od tempa zatwierdzania dokumentów u was. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/bezpieczenstwo-kodu-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability --- ## Zgodność z AI Act po stronie technicznej - Szkolenia i wdrożenia **URL:** https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zgodnosc-z-ai-act **Service type:** Doradztwo techniczne w zakresie zgodności z AI Act **Anchor:** Szkolenia, wdrożenia i nadzór (Szkolenia i wdrożenia) > 23Minds analizuje wymagania techniczne AI Act dla waszych systemów AI i przygotowuje dokumentację. Projektuje rejestrowanie decyzji, wersjonowanie modeli i możliwość uchylenia decyzji przez człowieka, a interpretację prawną weryfikuje wasz radca. ### Podsumowanie 23Minds dostarcza techniczną stronę zgodności z AI Act organizacjom, które budują, kupują albo stosują systemy AI. Usługa inwentaryzuje używane systemy AI, klasyfikuje je według poziomów ryzyka z rozporządzenia i pisze dokumentację techniczną w zakresie, jaki wynika z zastosowania systemu, waszej roli (dostawca albo podmiot stosujący) i terminów stosowania przepisów. Zbiera też wyniki testów: zakres, warunki, wyniki i wykryte ograniczenia. Rejestrowanie decyzji, wersjonowanie modeli i możliwość uchylenia decyzji przez człowieka są projektowane jako elementy architektury ze wskazanymi osobami odpowiedzialnymi. Zlecenie kończy się analizą luk, wycenioną mapą działań i planem kompetencji w zakresie AI. Pracę wykonują inżynierowie; interpretację obowiązków weryfikuje wasz radca albo kancelaria partnerska, a za spełnienie obowiązków odpowiada wasza organizacja. ### Dla kogo to jest - Startupy produktowe, których klienci wymagają uzasadnienia klasyfikacji ryzyka funkcji AI - Software house'y i integratorzy, którzy muszą oddać klientom dokumentację pod AI Act dla tego, co dostarczają - Zespoły w korporacjach i instytucjach publicznych, które stosują kupione systemy AI i mają obowiązki podmiotu stosującego - Organizacje regulowane w finansach, zdrowiu, HR, edukacji i infrastrukturze krytycznej z terminami audytów przed sobą - Osoby odpowiedzialne za zgodność, CISO, CTO i szefowie działów prawnych, którzy potrzebują artefaktów technicznych do podpisania przez radcę ### Problemy, które rozwiązujemy - Nikt nie umie przedstawić listy systemów AI, których organizacja naprawdę używa, a tym bardziej ich klasyfikacji ryzyka - Klient, przetarg albo audytor poprosił o dokumentację techniczną pod AI Act, a nic nie jest spisane - Systemy logują zdarzenia biznesowe, ale nie decyzje modelu, wejścia i wersje, których wymaga identyfikowalność - Nadzór człowieka istnieje na slajdzie, ale żaden interfejs, rola ani ścieżka eskalacji nie realizuje go na produkcji - Radca przekazał obowiązki, a zespół inżynierski nie wie, co w odpowiedzi zbudować ### Co dostajecie - Inwentaryzacja systemów AI z właścicielem, celem, przepływami danych, modelem i dostawcą przy każdym systemie - Klasyfikacja ryzyka każdego systemu według poziomów z rozporządzenia, z uzasadnieniem spisanym pod audyt i przegląd prawny - Pakiet dokumentacji technicznej dla każdego systemu w zakresie, ułożony według wymagań rozporządzenia - Specyfikacja logowania, identyfikowalności i nadzoru człowieka, ze zmianami w architekturze potrzebnymi do jej spełnienia - Wyniki testów z ewaluacji jakości i przeglądu bezpieczeństwa kodu systemu, tam gdzie są wymagane: zakres, warunki, wyniki, ograniczenia - Analiza luk i wyceniona mapa działań oraz plan kompetencji w zakresie AI przypisany do ról ### Jak pracujemy 1. **1. Inwentaryzacja** (Tydzień 1-2): Szukamy używanych systemów AI, zbudowanych, kupionych i wbudowanych w narzędzia zewnętrzne, na podstawie rejestrów, umów, rozmów z zespołami i przeglądu narzędzi. Przy każdym spisujemy cel, użytkowników, dane, model, dostawcę i osobę odpowiedzialną. Obszary, których nie dało się sprawdzić, oznaczamy w raporcie. 2. **2. Klasyfikacja ryzyka** (Tydzień 2-3): Klasyfikujemy każdy system według poziomów ryzyka z rozporządzenia i waszej roli wobec niego: dostawca albo podmiot stosujący. Uzasadnienie spisujemy tak, żeby radca mógł je potwierdzić albo podważyć. 3. **3. Analiza luk** (Tydzień 3-4): Porównujemy stan obecny z obowiązkami, które mają zastosowanie: dokumentacja, zarządzanie danymi, logowanie, identyfikowalność, nadzór człowieka, dokładność i odporność, dowody z testów, kompetencje w zakresie AI. 4. **4. Dokumentacja i dowody** (W projekcie, tygodnie 4-7): Piszemy pakiet dokumentacji technicznej, specyfikujemy architekturę logowania i nadzoru, zbieramy wyniki testów. Przeglądamy całość z waszym radcą albo naszym partnerem prawnym. 5. **5. Mapa działań i przekazanie** (W projekcie, tygodnie 7-8, potem przegląd co kwartał): Oddajemy wycenioną mapę działań z właścicielami i kolejnością, omawiamy ją z kierownictwem i ustalamy rytm przeglądu, który utrzymuje dokumentację aktualną, gdy systemy się zmieniają. ### FAQ **Q: Czy to jest porada prawna?** Nie, i mówimy to wprost. Jesteśmy zespołem inżynierskim. Produkujemy artefakty techniczne, których wymaga rozporządzenie: inwentaryzację, uzasadnienie klasyfikacji, dokumentację, projekt logowania i nadzoru, wyniki testów. Interpretację obowiązków weryfikuje wasz radca, a za ich spełnienie odpowiada wasza organizacja. Jeśli nie macie radcy od tego tematu, wprowadzamy do zlecenia partnera prawnego i dzielimy pracę jawnie. **Q: Obowiązki ciągle się zmieniają. Jak sobie z tym radzicie?** Pracujemy według obowiązków obowiązujących w chwili zlecenia i datujemy każdą klasyfikację oraz każdy dokument. Gdy interpretacja jest naprawdę otwarta, oznaczamy ją jako decyzję dla waszego radcy zamiast zgadywać. Zawsze zalecamy potwierdzenie prawne, zanim powołacie się na klasyfikację na zewnątrz. Kwartalny przegląd utrzymuje pakiet aktualny, gdy zmieniają się systemy i wytyczne. **Q: Ile to trwa i jak jest wyceniane?** Pakiet wejściowy dla jednego systemu to cztery tygodnie: klasyfikacja, inwentaryzacja, analiza luk i mapa działań, w cenie podanej na tej stronie. Pełne zlecenie z pakietem dokumentacji i mapą działań trwa zwykle 6-8 tygodni od startu. Cena projektu jest stała, ustalana po rozmowie wstępnej i zależy od liczby systemów w zakresie oraz od tego, ile z nich trafia do poziomu wysokiego ryzyka. **Q: Czego potrzebujecie od nas na start?** Dostępu do osób, które odpowiadają za każdy system AI, istniejącej dokumentacji architektury i przepływów danych, umów z dostawcami i umów powierzenia dla kupionej AI oraz wszelkich analiz prawnych i klasyfikacji zrobionych wcześniej. Braki uzupełniamy wywiadami; na tym etapie zwykle okazuje się, że prawdziwa lista systemów jest dłuższa niż ta w dokumentach. **Q: Używamy tylko systemów AI od dostawców. Czy to nas dotyczy?** Tak. Stosowanie systemu AI niesie własne obowiązki, osobne od obowiązków organizacji, która go zbudowała. Sprawdzamy, co naprawdę dają wam dostawcy, w tym instrukcje użytkowania, które dostawca ma obowiązek dostarczyć. Wskazujemy, czego w nich brakuje. Piszemy procedury po waszej stronie: projekt nadzoru człowieka, logowanie użycia i pytania do dostawcy przed odnowieniem umowy. **Q: Jak to się łączy z testowaniem i ewaluacją systemu?** Dowody z testów są jednym z artefaktów technicznych, które wspierają zgodność systemów wyższego ryzyka. Ewaluacja jakości działającej AI daje wyniki ewaluacji i oceniony zestaw testowy; przegląd bezpieczeństwa obejmuje kod i warstwę aplikacji. Obie usługi oddają ustalenia w formie, która wchodzi prosto do pakietu dokumentacji. Każdą można kupić osobno; prowadzone razem usuwają podwójne rozpoznanie i dają jeden spójny ślad dowodowy. **Q: A obowiązek zapewnienia kompetencji w zakresie AI?** To realny obowiązek. Rozpoznajemy, jakiego rozumienia AI potrzebuje każda rola, dobieramy szkolenia i sprawdzamy umiejętności potrzebne do pracy z systemem. Nasze programy szkoleń to realizują, a potwierdzenia ukończenia i wyniki sprawdzianów stają się częścią dowodów zgodności. **Q: Pracujecie zdalnie czy na miejscu? Czy możecie pracować w naszym środowisku?** Domyślnie zdalnie, pod NDA. Wywiady i warsztaty prowadzimy na miejscu, gdy daje to szybsze odpowiedzi, w tej samej cenie. Możemy pracować w całości w waszych narzędziach i systemach dokumentów, gdy materiały nie mogą opuścić organizacji. ### Powiązane - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/zasady-korzystania-z-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/ewaluacja-jakosci-ai - https://23minds.com/pl/uslugi/szkolenia-i-nadzor-ai/szkolenia-ai-z-dofinansowaniem --- # Ocena, audyt i bezpieczeństwo (anchor 02) **URL:** https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai **Highlight:** Ewaluacja kodu pisanego przez AI > 23Minds sprawdza kod pisany przez AI i wskazuje wykryte błędy oraz zalecane poprawki przed wydaniem: niezależna ewaluacja kodu, przegląd bezpieczeństwa, strategia testów i sprawdzenie gotowości produkcyjnej. ### Podsumowanie 23Minds prowadzi niezależną ewaluację kodu pisanego przez AI i innych wyników pracy inżynierskiej wspieranej przez AI. Audyt obejmuje kod waszego zespołu albo waszego dostawcy; 23Minds nie ocenia własnej pracy. Obszar obejmuje audyt kodu pisanego przez AI, przegląd bezpieczeństwa, strategię testów, sprawdzenie gotowości produkcyjnej i ewaluację jakości działającej AI na waszych danych. Każda z tych praktyk kończy się raportem z ustaleniami według wagi i dokumentami, które zostają u was: kartą ocen, listą poprawek, strategią testów albo listą kontrolną wydania. Badania kodu pisanego przez AI pokazują, czego szukać: w teście Veracode z 2026 roku ponad 100 modeli wybierało bezpieczną implementację średnio w 56% przypadków, a w badaniu 6 299 repozytoriów z 2026 roku 22,7% problemów wprowadzonych przez commity autorstwa AI zostało w najnowszej wersji kodu. Ustalenia dotyczące bezpieczeństwa raport przypisuje do kategorii OWASP Top 10 (edycja 2025), a przy funkcjach AI do OWASP Top 10 for LLM Applications. System zarządzania jakością firmy jest certyfikowany przez DNV (ISO 9001:2015, nr 10000439701-MSC-RvA-POL, ważny do 3.03.2027). ### Dla kogo to jest - Szefowie inżynierii, którzy wysyłają kod pisany z AI i potrzebują zewnętrznego potwierdzenia jego jakości - CTO firm regulowanych (finanse, zdrowie, sektor publiczny), których pytają o AI w kodzie - Zespoły bezpieczeństwa odpowiedzialne za produkty budowane z asystentami kodowania - Osoby odpowiedzialne za dostawców, które odbierają kod pisany z AI od firm zewnętrznych ### Problemy, które rozwiązujemy - Kod pisany przez AI trafia do PR-ów szybciej, niż ludzie są w stanie go dokładnie przeczytać - Dział zgodności pyta o dowód, że kod pisany przez AI spełnia te same wymagania co kod pisany ręcznie - Nowy kod trafia do repozytorium bez testów, które sprawdzałyby jego zachowanie, choć wygląda wiarygodnie - Zespół bezpieczeństwa nie wie, w których częściach kodu skupia się wkład AI ### Praktyki pod tym anchorem - Audyt kodu pisanego przez AI - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - Przegląd bezpieczeństwa kodu pisanego przez AI - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/bezpieczenstwo-kodu-ai - Pokrycie testowe - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/pokrycie-testowe - Gotowość produkcyjna - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna - Ewaluacja jakości działającej AI - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/ewaluacja-jakosci-ai ### FAQ **Q: Jak wygląda audyt kodu pisanego przez AI?** Cena audytu jest stała po ustaleniu zakresu na rozmowie wstępnej. Badamy uzgodnioną próbkę kodu pisanego przez AI z repozytorium albo z zestawu PR-ów, a zakres badania opisujemy w raporcie. Kod oceniamy według kryteriów: poprawność, bezpieczeństwo, utrzymywalność, jakość testów. Oddajemy pisemny raport z ustaleniami według wagi i omawiamy najważniejsze z zespołem. Pakiet dla jednego repozytorium trwa do 4 tygodni od zatwierdzenia zakresu. **Q: Czy zastępujecie przegląd kodu w naszym zespole?** Nie. Audyt uzupełnia przeglądy zespołu o okresowy, niezależny raport z wykrytymi problemami i zaleceniami. Można go zamawiać cyklicznie, na przykład raz na kwartał, obok własnego procesu. **Q: Jakie narzędzia obejmujecie?** Każdego asystenta kodowania opartego na modelu językowym: Cursor, Claude Code, Cody, Copilot, Windsurf, Aider. Oceniamy kod, który te narzędzia wygenerowały. W ankiecie Stack Overflow 2025 z narzędzi AI korzystało albo planowało korzystać 84% programistów odpowiadających na to pytanie, a wśród odpowiadających na pytanie o zaufanie 46% nie ufało dokładności wyników. **Q: Czy pracujecie pod NDA i w branżach regulowanych?** Tak. Podpisujemy umowę o poufności (NDA), potrafimy działać na odizolowanej infrastrukturze, a przy szczególnie wrażliwych systemach prowadzimy prace na miejscu, w waszym biurze. W branżach regulowanych przed startem ustalamy listę wymagań do sprawdzenia i wpisujemy wynik do raportu. **Q: Jak wygląda raport?** Ustrukturyzowany PDF plus wpisy z priorytetami w waszym systemie zgłoszeń (Linear, Jira albo GitHub Issues). Każde ustalenie ma wagę, odtworzenie, rekomendowaną poprawkę i odnośniki do kodu. Na życzenie sprawdzamy, czy poprawki weszły. **Q: Które przepisy sprawiają, że zewnętrzna ocena kodu ma znaczenie?** Akt o cyberodporności (rozporządzenie (UE) 2024/2847) od 11.09.2026 wymaga od producentów produktów z elementami cyfrowymi zgłaszania aktywnie wykorzystywanych podatności, z wczesnym ostrzeżeniem w ciągu 24 godzin, a w całości stosuje się od 11.12.2027. Dla systemów AI wysokiego ryzyka art. 15 AI Act (rozporządzenie (UE) 2024/1689) stawia wymogi dokładności, solidności i cyberbezpieczeństwa; po zmianie rozporządzeniem (UE) 2026/1744 stosuje się je od 2.12.2027 dla systemów z załącznika III i od 2.08.2028 dla AI w produktach regulowanych. O tym, czy system jest systemem wysokiego ryzyka, decyduje jego zastosowanie; samo pisanie kodu z asystentem tego nie przesądza. Raport z audytu nie czyni produktu zgodnym z przepisami. Dokumentuje, co sprawdzono, kiedy i kto to zrobił. --- ## Audyt kodu pisanego przez AI - Ocena i bezpieczeństwo **URL:** https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai **Service type:** Audyt kodu **Anchor:** Ocena, audyt i bezpieczeństwo (Ocena i bezpieczeństwo) > 23Minds prowadzi niezależny audyt kodu pisanego przez AI i z jej pomocą. Kod dostaje ocenę w czterech wymiarach: poprawność, bezpieczeństwo, utrzymywalność i jakość testów, według kryteriów, które czytacie w całości przed podpisaniem umowy. ### Podsumowanie 23Minds audytuje kod pisany przez AI dla zespołów, które chcą wiedzieć, w jakim stanie jest ten kod, przed wdrożeniem i po nim. Audyt jest niezależny, bo dotyczy kodu, którego zespół 23Minds nie pisał: waszego albo waszego dostawcy. Audyt bierze próbkę plików albo pull requestów z waszego repozytorium, dobraną według ryzyka. Ocenia ją w czterech wymiarach: poprawność, bezpieczeństwo, utrzymywalność, jakość testów. Kończy się raportem z ustaleniami uszeregowanymi według wagi i omówieniem z zespołem. Definicje wymiarów i skala 0-4 są na tej stronie, a kryteria składowe z wagami dostajecie przed podpisaniem umowy, więc wiecie, jak kod będzie oceniany, zanim kupicie. Pakiet wejściowy obejmuje jedno repozytorium; cena zależy od jego wielkości i złożoności, a po ustaleniu zakresu jest stała, z terminem do 4 tygodni od ustalenia zakresu. Badania kodu pisanego przez AI wskazują problemy, których warto szukać w audycie: słabości bezpieczeństwa miało 29,5% fragmentów w Pythonie napisanych przez asystentów w publicznych projektach na GitHubie (Fu i współautorzy, ACM TOSEM 2025), a 22,7% problemów wprowadzonych przez commity autorstwa AI w 6 299 repozytoriach zostało w najnowszej wersji kodu (Liu i współautorzy, 2026). ### Dla kogo to jest - CTO i szefowie inżynierii, którzy potrzebują zewnętrznego potwierdzenia jakości kodu pisanego z AI - CISO, których zespoły wdrażają kod od AI do systemów produkcyjnych pod nadzorem regulatora - Osoby odpowiedzialne za dostawców, które odbierają kod pisany z AI od firm zewnętrznych - Osoby odpowiedzialne za zgodność, które muszą pokazać audytorowi zakres i szczegółowość przeglądu kodu ### Problemy, które rozwiązujemy - Kod pisany przez AI trafia do repozytorium szybciej, niż ludzie są w stanie go dokładnie przeczytać - Dział zgodności pyta o dowód, że kod pisany z AI spełnia tę samą poprzeczkę co kod pisany ręcznie - Ustalenia z audytów przychodzą jako opinie bez opisanej metody, więc nikt nie umie ich powtórzyć ani podważyć - Nowy kod trafia do repozytorium bez testów, które sprawdzałyby jego zachowanie, choć wygląda wiarygodnie - Zespół bezpieczeństwa nie wie, w których częściach kodu skupia się wkład AI ### Co dostajecie - Pisemny raport z audytu (PDF, ok. 30-60 stron zależnie od zakresu) - Karta ocen dla każdego wymiaru na opublikowanej skali 0-4, z opisem warunków przyznania każdej oceny i wagami uzgodnionymi dla waszego kontekstu - Lista ustaleń według wagi (krytyczne, wysokie, średnie, niskie) z odtworzeniem każdego - Rekomendowana poprawka przy każdym ustaleniu, z fragmentami kodu i odnośnikami do linii - Wpisy w waszym systemie zgłoszeń z ustalonymi priorytetami (Linear, Jira albo GitHub Issues) - Prezentacja dla zarządu z najważniejszymi ustaleniami i planem naprawy ### Jak pracujemy 1. **1. Zakres i próbka** (Tydzień 1): Ustalamy zakres audytu: które repozytoria, jaki okres PR-ów i, jeśli to wiecie, jakie narzędzia wyprodukowały kod. Przechodzimy razem kryteria i uzgadniamy wagi dla waszego kontekstu. 2. **2. Ocena** (Tydzień 2-3): Oceniamy próbkę kodu w czterech wymiarach. Odtwarzamy każde ustalenie, oceniamy każdy wymiar na opublikowanej skali, spisujemy wagę i rekomendowaną poprawkę. 3. **3. Raport i omówienie** (Tydzień 3-4): Oddajemy pisemny raport, omawiamy najważniejsze ustalenia z kierownictwem i zespołem inżynierskim, zakładamy wpisy w waszym systemie zgłoszeń. 4. **4. Ponowny przegląd po poprawkach (opcjonalnie)** (Tydzień 4-8 po raporcie): Po 4-8 tygodniach sprawdzamy, czy poprawki usunęły wskazane problemy. Jeśli standard jest spełniony, wystawiamy potwierdzenie zamknięcia ustaleń. ### FAQ **Q: Ile kosztuje audyt?** Pakiet wejściowy dla jednego repozytorium ma cenę od, podaną w cenniku na tej stronie: nakład zależy od wielkości i złożoności kodu, a po ustaleniu zakresu na rozmowie wstępnej cena jest stała, bez ukrytych kosztów. Większy zakres (kilka repozytoriów, cała platforma, bramki jakości w CI) wyceniamy po rozmowie wstępnej, gdy zakres jest jasny. **Q: Według jakich kryteriów oceniacie kod?** W czterech wymiarach, każdy z opublikowaną definicją. Poprawność: czy kod robi to, co mówią ticket i testy, razem z przypadkami brzegowymi i ścieżkami błędów. Bezpieczeństwo: czy wprowadza podatności, niebezpieczne ustawienia domyślne, słabą obsługę sekretów albo ryzyko w zależnościach. Utrzymywalność: czy następny inżynier zrozumie, znajdzie i zmieni ten kod bez czytania całego systemu. Jakość testów: czy testy obejmują istotne scenariusze i wykrywają błędne działanie kodu, czy tylko podbijają pokrycie. Każdy wymiar ma nazwane kryteria składowe z wagami dopasowanymi do waszego kodu. **Q: Jak wygląda skala ocen?** Opublikowana skala 0-4 ze stałymi kotwicami: 0 to defekt blokujący, wydanie musi stanąć; 1 to poważne braki wymagające przeróbki przed wydaniem; 2 to kod, który działa, ale z istotnymi ustaleniami i długiem do zaplanowania; 3 to spełniona poprzeczka z drobnymi ustaleniami; 4 to brak ustaleń w badanej próbce w tym wymiarze. Każda ocena w raporcie wskazuje warunek, na którym została przyznana, więc możecie podważyć pojedynczą ocenę zamiast całego raportu. Kryteria, kryteria składowe i skala nie zmieniają się między zleceniami, więc możecie stosować je do własnych PR-ów między audytami. **Q: Czy pracujecie pod NDA i w branżach regulowanych?** Tak. Standardowe NDA, praca na odizolowanej infrastrukturze, a przy szczególnie wrażliwych systemach audyt na miejscu, w waszym biurze. Gdy podlegacie regulacjom (DORA i wytyczne KNF w finansach, RODO w ochronie zdrowia), przed startem ustalamy listę wymagań do sprawdzenia. Wynik wpisujemy do raportu. **Q: Czy zastępujecie nasz wewnętrzny przegląd kodu?** Nie. Audyt jest zewnętrznym potwierdzeniem: okresowym, niezależnym i głębszym niż codzienny przegląd. Można go zamawiać cyklicznie, na przykład raz na kwartał, obok własnego procesu. **Q: Czy zrobicie ponowny audyt po poprawkach?** Tak. Przy pakiecie wejściowym ponowny audyt po naprawie wyceniamy na połowę ceny pakietu; w projekcie ponowny przegląd jest w zakresie. Kończy się potwierdzeniem, które ustalenia zostały zamknięte. Przydaje się do raportu dla zarządu albo przed audytem zewnętrznym. **Q: Co mówią opublikowane badania o jakości kodu pisanego przez AI?** Wyniki zależą od badanego problemu. W prawdziwych projektach na GitHubie słabości bezpieczeństwa miało 29,5% fragmentów w Pythonie i 24,2% w JavaScripcie napisanych przez asystentów (Fu i współautorzy, ACM TOSEM 2025, 733 fragmenty). W 576 tys. próbek kodu z 16 modeli 19,7% z 2,23 mln odwołań do pakietów wskazywało pakiety, które nie istnieją (Spracklen i współautorzy, USENIX Security 2025). Eksperyment kontrolowany ze 151 uczestnikami nie wykazał systematycznej różnicy w utrzymywalności kodu napisanego z asystentem AI w porównaniu z kodem napisanym bez niego (Borg i współautorzy, ICSME 2025). Audyt sprawdza bezpieczeństwo, zależności, utrzymywalność i testy w uzgodnionej próbce waszego kodu. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/bezpieczenstwo-kodu-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability --- ## Przegląd bezpieczeństwa kodu pisanego przez AI - Ocena i bezpieczeństwo **URL:** https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/bezpieczenstwo-kodu-ai **Service type:** Przegląd bezpieczeństwa aplikacji **Anchor:** Ocena, audyt i bezpieczeństwo (Ocena i bezpieczeństwo) > Przegląd bezpieczeństwa kodu pisanego przez AI: wstrzyknięcia, niebezpieczne ustawienia domyślne, obsługa sekretów, wygenerowana logika uprawnień. Do tego funkcje AI w aplikacji, jeśli je ma. Wynik to wykryte problemy z krokami odtworzenia i gotową poprawką. ### Podsumowanie 23Minds sprawdza bezpieczeństwo kodu pisanego przez AI oraz funkcji AI w aplikacji, jeśli produkt je ma. Przegląd obejmuje części repozytorium, które powstały z AI, razem z kodem, z którym się łączą: wstrzyknięcia, niebezpieczne ustawienia domyślne, obsługę sekretów, zależności wybrane przez asystenta, wygenerowaną logikę uprawnień i obsługę błędów, która zdradza wnętrze systemu. W funkcjach AI sprawdza, jak aplikacja buduje prompty, czemu ufa w odpowiedzi modelu, co wolno wywołać agentowi i co dzieje się z odpowiedzią, zanim trafi do użytkownika albo do bazy. Każdy wykryty problem ma kroki odtworzenia i gotową poprawkę, a zespół dostaje reguły przeglądu, żeby ta sama klasa problemu zatrzymywała się na code review. To przegląd na poziomie kodu: infrastruktura, chmura i bezpieczeństwo organizacji są poza zakresem z założenia. ### Dla kogo to jest - Zespoły produktowe, które wdrożyły asystenta AI i wysyłają kod szybciej, niż ktokolwiek sprawdza go pod kątem bezpieczeństwa - Software house'y i agencje oddające kod pisany z AI, których klienci zaczęli prosić o niezależną opinię o jego bezpieczeństwie - Firmy, które dodały funkcję opartą na modelu językowym (czat, streszczenia, agent w aplikacji) do istniejącego produktu i chcą sprawdzić, co odsłoniła - Szefowie inżynierii, CTO zespołów produktowych i tech leadzi, którzy chcą dostać ustalenia prosto w repozytorium ### Problemy, które rozwiązujemy - Asystent w tempie napisał budowanie zapytań, obsługę plików i parsowanie żądań, a nikt nie sprawdził tych ścieżek pod kątem wstrzyknięć - Wygenerowany kod niesie ustawienia domyślne frameworka, które model akurat znał: liberalny CORS, wyłączona weryfikacja, szczegóły błędów na produkcji - Sekrety i tokeny są obsługiwane tak, jak pokazał asystent: w kodzie, w logach, w paczce dla przeglądarki - Kontrole uprawnień zostały wygenerowane osobno dla każdego endpointu i wymagają sprawdzenia, czy są spójne i obecne wszędzie - Instrukcje od użytkownika mogą zmienić zachowanie modelu albo uruchomić niedozwolone narzędzia, a odpowiedź modelu idzie prosto do HTML, do wywołania powłoki albo do zapisu w bazie - Agent w aplikacji ma dostęp do narzędzi i poświadczeń znacznie szerszy niż zadanie, które wykonuje ### Co dostajecie - Lista wykrytych problemów według wagi (krytyczne, wysokie, średnie, niskie), każdy z krokami odtworzenia oraz dokładnym plikiem i liniami - Gotowa poprawka przy każdym problemie: patch, diff albo przykład, który wasz zespół dostosowuje, testuje i wdraża (wdrożenie jest poza pakietem wejściowym) - Przegląd funkcji AI w aplikacji: budowanie promptów, granice zaufania wokół API modelu, obsługa odpowiedzi, zakres narzędzi i uprawnień agenta - Ustalenia o sekretach i zależnościach w kodzie pisanym z AI, w tym pakiety wprowadzone przez asystenta - Krótki zestaw reguł przeglądu dla zespołu: czego szukać w PR-ach pisanych z AI, jako lista kontrolna i jako reguły lintera lub CI tam, gdzie da się je zautomatyzować; kontrole trafiają do was jako PR do pipeline, a wdraża je wasz zespół albo 23Minds z dodatkowym dostępem - Sesja robocza z zespołem inżynierskim o najważniejszych ustaleniach i o tym, jak każde z nich powstało ### Jak pracujemy 1. **1. Zakres i przejście przez kod** (Tydzień 1): Uzgadniamy, które repozytoria i który kod pisany przez AI wchodzą w zakres, który asystent go wyprodukował i gdzie siedzą funkcje AI. Pochodzenie zmian ustalamy z historii PR-ów i z wami. Przechodzimy przez kod z doświadczonym inżynierem z waszej strony. 2. **2. Przegląd bezpieczeństwa kodu** (Tydzień 1-2): Czytamy kod pisany przez AI pod kątem wstrzyknięć, niebezpiecznych ustawień domyślnych, obsługi sekretów, wygenerowanej logiki uprawnień, wyboru zależności i obsługi błędów, która zdradza wnętrze. Odtwarzamy to, co znajdziemy. 3. **3. Przegląd funkcji AI w aplikacji** (Tydzień 2-3): Śledzimy, jak dane od użytkownika trafiają do promptu, co aplikacja wysyła do API modelu i czemu ufa w odpowiedzi, co wolno wywołać agentowi w aplikacji i co dzieje się z odpowiedzią, zanim trafi do użytkownika albo do bazy. 4. **4. Raport, poprawki i reguły przeglądu** (Tydzień 3-4): Oddajemy listę ustaleń z poprawkami, omawiamy najważniejsze z zespołem i przekazujemy reguły przeglądu oraz kontrole w CI, które wyłapią te same klasy problemów w przyszłych PR-ach. ### FAQ **Q: Czym to się różni od audytu kodu pisanego przez AI?** Audyt kodu ocenia kod pisany przez AI w czterech wymiarach (poprawność, bezpieczeństwo, utrzymywalność, jakość testów) i daje ogólny obraz. Przegląd bezpieczeństwa bierze tylko wymiar bezpieczeństwa i idzie znacznie głębiej: każdy problem doprowadzamy do działającego odtworzenia i poprawki w kodzie. Sprawdzamy też funkcje AI w aplikacji, które audyt tylko próbkuje. Zespoły, które chcą jednego szerokiego obrazu, kupują audyt; zespoły, które już wiedzą, że chodzi o bezpieczeństwo, kupują ten przegląd. **Q: Czego wprost nie robicie?** Nie zajmujemy się bezpieczeństwem infrastruktury, chmury ani sieci, testami penetracyjnymi działających systemów, ofensywnym red teamingiem wdrożonej AI, programami audytu SOC 2 i ISO 27001 ani nadzorem nad bezpieczeństwem w organizacji. Nie oceniamy też waszego dostawcy modeli jako organizacji; sprawdzamy pakiety i zależności, które asystent wprowadził do kodu. Przeglądamy kod i to, co ten kod wystawia na zewnątrz. Zakresy z tej listy wymagają osobnego badania; jego wykonawcy przekażemy nasz raport, żeby zaczynał od konkretu. **Q: Jakiego dostępu potrzebujecie?** Dostępu do odczytu repozytoriów w zakresie, historii PR-ów z okresu pracy z asystentem oraz działającej instancji w środowisku nieprodukcyjnym, żeby odtwarzać ustalenia. Bez dostępu do produkcji i bez danych klientów. Do tego doświadczony inżynier z waszej strony: na przejście przez kod na starcie i na omówienie ustaleń na końcu. Wszystko pod NDA. **Q: Ile to trwa?** Pakiet dla jednej aplikacji to cztery tygodnie od zatwierdzenia zakresu. Pojedynczy serwis albo dobrze wydzielona funkcja AI zamyka się szybciej; duża baza w wielu repozytoriach dostaje kilka osobnych przebiegów zamiast jednego długiego przeglądu. Cena jest stała i ustalona, gdy zakres jest jasny. **Q: Pracujecie zdalnie czy na miejscu?** Domyślnie zdalnie, pod NDA, na dostępie do waszego repozytorium. Na miejscu w Polsce, gdy polityka klienta wymaga, żeby kod nie opuszczał jego sieci, w tej samej cenie. **Q: Co zespół dostaje na później?** Listę ustaleń z poprawkami, reguły przeglądu jako listę kontrolną i to, co udało się zamienić w kontrole lintera albo CI. Chodzi o to, żeby następny PR pisany z asystentem zatrzymał wasz własny przegląd, a nie my. Po kilku miesiącach ma sens krótszy ponowny przegląd zamiast powtórki całego zlecenia. **Q: Jakie języki i technologie obejmujecie?** TypeScript i JavaScript, Python, Go, Ruby, Java i Kotlin oraz popularne frameworki webowe wokół nich. Aplikacje mobilne i systemy wbudowane są poza zakresem tej praktyki. Powiedzcie nam o technologii na rozmowie wstępnej, a powiemy wprost, czy jesteśmy do tego właściwym zespołem. **Q: Czy musimy mieć wdrożoną funkcję AI, żeby to kupić?** Nie. Przegląd obejmuje też zwykły produkt, w którym jedyną AI był asystent pomagający pisać kod. Jeśli produkt nie ma funkcji opartej na modelu językowym, pomijamy fazę trzecią, a ten czas idzie na przegląd kodu. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna --- ## Pokrycie testowe - Ocena i bezpieczeństwo **URL:** https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/pokrycie-testowe **Service type:** Strategia i implementacja testów **Anchor:** Ocena, audyt i bezpieczeństwo (Ocena i bezpieczeństwo) > 23Minds audytuje testy i wdraża testy krytycznych procesów w oprogramowaniu z kodem pisanym przez AI. Strategia mówi, co testować, co zastępować atrapą i co pominąć, a testy wykrywają błędy po kolejnych zmianach. ### Podsumowanie 23Minds projektuje i wdraża strategię pokrycia testami dla zespołów, które wysyłają kod pisany przez AI. Testy pisane z AI często wyglądają na dokładne, ale sprawdzają to, co kod robi, a nie to, co powinien robić, więc wysokie pokrycie nie potwierdza zgodności z wymaganiami. Usługa audytuje obecne testy i projektuje strategię pokrycia powiązaną z ryzykiem produktu: procesy, których awaria ma największe skutki, dostają testy w pierwszej kolejności. Gdy testów nie ma, praca zaczyna się od wymagań, kodu i wyboru ścieżek krytycznych. Pakiet wejściowy obejmuje jedno repozytorium, pisemną strategię i do 20 testów ścieżek krytycznych działających w CI. Sygnały w CI i podręcznik pisania testów z AI są w zakresie projektu. ### Dla kogo to jest - Menedżerowie inżynierii, u których kod pisany przez AI powstaje szybciej, niż nadążają testy - Tech leadzi, którzy patrzą, jak rośnie procent pokrycia i razem z nim liczba regresji - CTO, którzy chcą skalować mały zespół z AI bez utraty jakości - Szefowie QA, którzy dostosowują strategię do kodu pisanego przez AI ### Problemy, które rozwiązujemy - Testy pisane z AI przechodzą, ale nie sprawdzają zachowania ważnego dla biznesu - Procent pokrycia rośnie, a razem z nim liczba regresji zgłaszanych przez klientów - Atrapy mnożą się, gdy AI zapełnia luki; zestaw testuje sam siebie, a nie system - W testach brakuje scenariuszy obejmujących bazę danych, kolejki i zewnętrzne API, a nikt ich nie pisze ### Co dostajecie - Audyt obecnego zestawu testów: co sprawdza zgodność z wymaganiami, a co tylko podbija wskaźniki - Dokument strategii testów powiązanej z ryzykiem: co testować, co zastępować atrapą, co pominąć - Testy ścieżek krytycznych napisane według uzgodnionych wymagań i wpięte w CI - W zakresie projektu: konfiguracja CI z sygnałami o rodzaju problemu (niestabilne testy, alerty o regresjach) - W zakresie projektu: podręcznik dla zespołu ze wzorcami promptów do pisania dobrych testów z AI ### Jak pracujemy 1. **1. Audyt testów** (Tydzień 1): Próbkujemy istniejące testy w modułach. Oceniamy każdy: sprawdza zgodność z wymaganiami czy tylko podbija wskaźnik. Wskazujemy luki na ścieżkach krytycznych. Gdy testów nie ma, zaczynamy od wymagań i kodu. 2. **2. Projekt strategii** (Tydzień 1-2): Mapujemy ryzyko produktu na strategię testów. Ustalamy proporcje testów jednostkowych, integracyjnych i E2E. Decydujemy, co zastąpić atrapą, a co uruchamiać naprawdę. 3. **3. Implementacja** (Tydzień 2-3): Piszemy testy ścieżek krytycznych według uzgodnionych wymagań i wpinamy je w CI. W projekcie ustawiamy też sygnały w CI i spisujemy wzorce promptów do testów pisanych z AI. 4. **4. Przekazanie zespołowi** (Tydzień 3): Omawiamy strategię z zespołem i przekazujemy testy. W projekcie pracujemy w parach nad nowymi testami według podręcznika i ustalamy rytm przeglądu. ### FAQ **Q: Dlaczego AI źle pisze niektóre testy?** Poprawny test wymaga wymagań, danych testowych i wiedzy o zależnościach systemu, a asystent ma w kontekście tylko część z tego. Dlatego testy jednostkowe na widocznych sygnaturach funkcji wychodzą mu dobrze, testy integracyjne zależne od stanu systemu gorzej, a testy E2E z rozbudowanym przygotowaniem danych najsłabiej. W efekcie zestaw jest mocny w łatwych miejscach i słaby tam, gdzie siedzi ryzyko. **Q: Czy podniesiecie nam procent pokrycia?** Optymalizujemy zgodność działania z wymaganiami, a nie surowy procent pokrycia. Usuwamy testy, które dublują inne albo nie wykrywają błędów, więc procent może spaść, bo część pokrycia pochodziła z takich testów. Przy odbiorze raportujemy, ile celowych uszkodzeń kodu zestaw wyłapał przed zleceniem i po nim. Obserwację regresji po wdrożeniu ustalamy osobno. **Q: Czy możecie pracować z naszym obecnym CI?** Tak. GitHub Actions, GitLab CI, CircleCI, Jenkins, Buildkite; pracujemy na tym, co macie. Nie wprowadzamy nowych narzędzi CI bez mocnego powodu. **Q: Jakie języki obejmujecie?** TypeScript i JavaScript, Python, Go, Ruby, Java i Kotlin. Aplikacje mobilne (Swift, Kotlin) i systemy wbudowane są poza zakresem tej praktyki. **Q: Jak to się łączy z audytem kodu pisanego przez AI?** Audyt kodu ocenia poprawność tego, co już jest. Pokrycie testowe buduje zestaw, który wykrywa regresje w objętych testami scenariuszach, zanim trafią na produkcję. Te dwie praktyki dobrze działają w parze. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/budowa-oprogramowania-z-ai --- ## Gotowość produkcyjna - Ocena i bezpieczeństwo **URL:** https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna **Service type:** Przegląd gotowości produkcyjnej **Anchor:** Ocena, audyt i bezpieczeństwo (Ocena i bezpieczeństwo) > 23Minds sprawdza, czy wasz zespół wykryje awarię systemu, dostanie powiadomienie i przywróci jego działanie. Ocena według ustalonej karty, przed wydaniem albo przed przejęciem działającego systemu na utrzymanie. ### Podsumowanie 23Minds prowadzi przeglądy gotowości produkcyjnej systemów z kodem pisanym przez AI albo z funkcjami opartymi na modelach: przed wydaniem albo przed przejęciem działającego systemu na utrzymanie. Przegląd ocenia system według ustalonej karty: pokrycie monitoringiem i tracingiem, jakość runbooków, procedura wycofania, alerty dla dyżuru, zapas mocy, monitoring kosztów, tryby awarii zależności. Kończy się raportem z listą wymagań naprawczych i, gdy wynik na to pozwala, pisemnym oświadczeniem o gotowości. Tego dokumentu potrzebują zespoły SRE i platformy, żeby podpisać wydanie. Pakiet wejściowy obejmuje jeden system w stałej cenie; ponowna ocena po poprawkach jest w zakresie projektu. ### Dla kogo to jest - Szefowie inżynierii, którzy podpisują start nowej funkcji AI - Szefowie SRE i platformy, których poproszono o wzięcie systemu AI na dyżur - CTO firm w fazie wzrostu, które wypuszczają pierwszy produkt oparty na modelu językowym - Product managerowie, których start zależy od tego, czy inżynieria i SRE powiedzą tak ### Problemy, które rozwiązujemy - Funkcje AI startują bez monitoringu; debugowanie na produkcji to zgadywanie - Runbooków dla nowego systemu nie ma albo nikt ich nie przetestował - Procedury wycofania nikt nigdy nie uruchomił; awaria na produkcji zamienia się w wielogodzinny przestój - Nie ma monitoringu kosztów; pierwszy rachunek za modele językowe jest zaskoczeniem ### Co dostajecie - Karta gotowości produkcyjnej: 10-15 wymiarów ocenionych jako spełnia, częściowo albo nie spełnia, z dowodem przy każdej ocenie - Pisemne oświadczenie o gotowości z wymaganiami naprawczymi, jeśli są potrzebne - Szablony runbooków dla nowego systemu, przetestowane z zespołem dyżurnym - Dokumentacja procedury wycofania, przećwiczonej na sucho na stagingu - Rekomendacje konfiguracji monitoringu kosztów i zapasu mocy oraz lista alertów do usunięcia albo zmiany ### Jak pracujemy 1. **1. Przegląd systemu** (Tydzień 1): Przeglądamy architekturę, stos monitoringu, runbooki, procedury dyżuru, plan pojemności i ustawienia monitoringu kosztów. 2. **2. Sprawdzenie w praktyce** (Tydzień 2): Testujemy procedurę wycofania na stagingu. Ćwiczymy runbooki z zespołem dyżurnym. Wywołujemy alerty testowe i sprawdzamy, czy dochodzą do właściwych osób. Zachowanie pod obciążeniem oceniamy na podstawie waszych wyników testów i konfiguracji; same testy obciążeniowe są osobnym zakresem. 3. **3. Ocena i lista wymagań naprawczych** (Tydzień 2-3): Oceniamy według karty. Spisujemy wymagania naprawcze z priorytetami. Przygotowujemy oświadczenie o gotowości. 4. **4. Ponowna ocena (gdy potrzebne są poprawki)** (1-2 tygodnie po poprawkach): Sprawdzamy ponownie wymiary po naprawie i wydajemy końcowe oświadczenie. W zakresie projektu. ### FAQ **Q: Czy możecie potwierdzić gotowość systemu w trzy tygodnie?** Tak, gdy system ma już przyzwoity monitoring. Systemy bez podstaw (bez tracingu, bez runbooków) zwykle potrzebują 4-6 tygodni na poprawki, zanim oświadczenie ma sens. **Q: Co obejmuje karta oceny?** Pokrycie monitoringiem, głębokość tracingu, jakość runbooków, procedurę wycofania, alerty dla dyżuru, zapas mocy, monitoring kosztów, tryby awarii zależności, podstawy bezpieczeństwa, ryzyka specyficzne dla AI (wstrzyknięcie promptu, zmiana zachowania modelu) i gotowość do obsługi incydentu. **Q: Czy piszecie runbooki za nas?** Dajemy szablony i przeglądamy to, co napisze zespół. Nie piszemy runbooków, których zespół nie sprawdził: instrukcja, której dyżur nigdy nie przećwiczył, nikogo nie chroni. **Q: Czy możecie potwierdzać gotowość cyklicznie, nie tylko przy starcie?** Tak. Kwartalne ponowne potwierdzenie to typowy układ stałej współpracy. Przydaje się, gdy funkcje AI szybko się zmieniają, albo jako sygnał dla zarządu przy systemach krytycznych dla działania firmy. **Q: Czym to się różni od przeglądu bezpieczeństwa?** Przegląd bezpieczeństwa pyta, czy system da się nadużyć: z zewnątrz, z wewnątrz, przez uprawnienia albo dane. Gotowość produkcyjna pyta, czy system wytrzyma ruch i czy zespół szybko go naprawi, gdy się zepsuje; z bezpieczeństwa sprawdza tylko podstawy z karty. Większość wydań potrzebuje obu odpowiedzi przed startem. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/bezpieczenstwo-kodu-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability --- ## Ewaluacja jakości działającej AI - Ocena i bezpieczeństwo **URL:** https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/ewaluacja-jakosci-ai **Service type:** Ewaluacja jakości systemów AI **Anchor:** Ocena, audyt i bezpieczeństwo (Ocena i bezpieczeństwo) > 23Minds ewaluuje AI, która działa w waszym produkcie albo procesie, albo jest tuż przed wydaniem: jakość odpowiedzi, zgodność ze źródłami, skuteczność agenta i to, czy krok z AI naprawdę skraca proces. Ocena według kryteriów uzgodnionych z wami. ### Podsumowanie 23Minds ewaluuje jakość rozwiązań AI, które działają albo są przed wydaniem: funkcji opartych na modelach językowych w produkcie, odpowiedzi opartych na wyszukiwaniu w dokumentach (RAG) i procesów z agentami, które biegną bez nadzoru człowieka. Ewaluacja dotyczy rozwiązań, których zespół 23Minds nie budował. 23Minds sprawdza rozwiązanie na zestawie testowym zbudowanym z waszych przypadków, według kryteriów uzgodnionych z osobą odpowiedzialną za wynik biznesowy. Raport pokazuje wyniki, błędy wpływające na wynik i zalecane poprawki dla każdego powtarzającego się wzorca. Zestaw i kryteria zostają u was, wpięte w CI jako bramka jakości, która wykrywa regresję w sprawdzanych przypadkach przy następnej zmianie modelu, promptu albo dostawcy. Usługa nie zależy od narzędzia: działa na waszym stosie ewaluacyjnym albo pomaga go wybrać. ### Dla kogo to jest - Zespoły produktowe, które wdrożyły funkcję opartą na modelu językowym i nie mają jak sprawdzić, czy odpowiedzi są naprawdę dobre - Firmy z wewnętrznym asystentem AI, którego użycie stoi w miejscu i nikt nie mierzy, czy komuś pomaga - Zespoły przed zmianą modelu, sposobu budowania promptów albo dostawcy, które boją się regresji, której nikt nie zauważy - Szefowie operacji i usług wspólnych, którzy wstawili krok z AI do procesu i muszą udowodnić, że proces się skrócił, a nie przeniósł pracę na kogoś innego - Szefowie inżynierii, danych i wsparcia, którzy zaczęli od darmowego narzędzia do ewaluacji, mają ślady wywołań i stanęli na zestawie testowym ### Problemy, które rozwiązujemy - Funkcja oparta na modelu językowym działa, a jedynym sygnałem jakości jest skarga albo zgłoszenie do wsparcia - Odpowiedzi RAG czytają się płynnie, ale nikt nie sprawdził, czy są zgodne z właściwym dokumentem źródłowym - Procesy z agentami raportują sukces, a człowiek po cichu kończy zadanie i nikt nie liczy, jak często - Zmiana promptu albo modelu wchodzi na produkcję, a regresję odkrywają użytkownicy, zanim zauważy ją zespół - Zespół wziął darmowe narzędzie do ewaluacji i stanął na dwóch rzeczach: budowie zestawu testowego i uzgodnieniu, co znaczy dobrze ### Co dostajecie - Zestaw ewaluacyjny zbudowany z waszego ruchu i przypadków brzegowych, w waszych narzędziach, po zleceniu wasz - Kryteria oceny z wagami wymiarów (poprawność, zgodność ze źródłami, wykonanie zadania, format i ton, koszt i opóźnienie), uzgodnione z osobą odpowiedzialną za wynik biznesowy - Karta wyników bazowych: każdy przypadek oceniony, wyniki w podziale na wymiar, ścieżkę użytkownika oraz wersję modelu albo promptu - Raport wzorców błędów z odtworzeniem, przyczyną i zaleceniem naprawy dla każdego wzorca (samą naprawę robi wasz zespół albo osobne zlecenie) - Bramka jakości w CI: zestaw ewaluacyjny jako blokująca kontrola przy zmianach promptu, modelu, wyszukiwania i dostawcy - W zakresie projektu: odczyt skuteczności procesu (gdzie krok z AI skraca proces, a gdzie przenosi pracę na człowieka) oraz rekomendacja narzędzia z porównaniem kosztu własnego hostingu i SaaS przy waszej skali ### Jak pracujemy 1. **1. Zakres i kryteria** (Tydzień 1): Uzgadniamy z osobami odpowiedzialnymi za wynik, co znaczy dobrze dla tego rozwiązania. Definiujemy wymiary jakości, ich wagi i próg zaliczenia. Ustalamy liczbę ewaluacji w zakresie. 2. **2. Budowa zestawu ewaluacyjnego** (Tydzień 1-2): Składamy przypadki testowe z waszego ruchu, znanych błędów i przypadków brzegowych nieuwzględnionych w dotychczasowych testach. Do każdego dodajemy oczekiwaną odpowiedź albo kryteria oceny. Wpinamy zestaw w wasze narzędzie ewaluacyjne albo w to, które pomagamy wybrać. 3. **3. Ocena i analiza** (Tydzień 2-3): Oceniamy każdy przypadek według kryteriów: automatycznie, modelem oceniającym i przeglądem człowieka tam, gdzie kryteria wymagają oceny. Grupujemy błędy we wzorce i ustalamy przyczynę każdego: wyszukiwanie, prompt, wybór modelu, podpięcie narzędzi albo projekt procesu. 4. **4. Raport i przekazanie** (Tydzień 3-4): Oddajemy kartę wyników bazowych i raport wzorców błędów, omawiamy je z właścicielami produktu i inżynierii, przekazujemy zestaw i kryteria wpięte w CI jako bramkę, którą wasz zespół uruchamia bez nas. 5. **5. Ciągła ewaluacja (opcjonalnie)** (Ciągle): Stała współpraca: utrzymujemy i rozszerzamy zestaw, uruchamiamy go po każdej zmianie modelu, promptu albo dostawcy i raportujemy regresję, zanim znajdą ją użytkownicy. ### FAQ **Q: Co dokładnie jest w cenie i jak ją liczycie?** Jednostką pracy jest jedna ewaluacja: jeden przypadek testowy oceniony według uzgodnionych kryteriów. W zakresie ustalamy liczbę ewaluacji, kryteria i raportowanie, więc widzicie, za co płacicie. Pakiet wejściowy dla jednej funkcji albo agenta ma stałą cenę podaną w cenniku na tej stronie. Większy zakres wyceniamy po rozmowie wstępnej według liczby ewaluacji i liczby rozwiązań. **Q: Ile to trwa i czego potrzebujecie od nas?** Cztery tygodnie od zatwierdzenia zakresu do przekazania. Od was: jedna osoba odpowiedzialna za wynik biznesowy, która uzgodni kryteria, jeden inżynier od dostępów i narzędzi, próbka prawdziwego ruchu albo logów oraz znane przypadki błędów, jeśli je zbieracie. Warsztat o kryteriach i sesja przekazania zajmują po około pół dnia; reszta dzieje się po naszej stronie. **Q: Czym to się różni od audytu kodu pisanego przez AI?** Audyt kodu ocenia kod: poprawność, bezpieczeństwo, utrzymywalność i jakość testów tego, co napisał wasz zespół i jego narzędzia AI. Ewaluacja jakości ocenia zachowanie wdrożonego rozwiązania: czy odpowiedzi są trafne i umocowane w źródłach, czy agent kończy zadanie, czy proces naprawdę się skrócił. Czysty kod może dawać system, który odpowiada źle. Bywa też odwrotnie. Obie usługi da się kupić razem, zwykle w tej kolejności. **Q: Czy potrzebujecie dostępu do naszych danych produkcyjnych?** Niekoniecznie. Możemy pracować na przypadkach zanonimizowanych albo syntetycznych wyprowadzonych z waszych prawdziwych; tak pracuje wielu klientów regulowanych. Gdy dostajemy dostęp do produkcji, pracujemy pod umową o poufności (NDA), na waszej infrastrukturze, a dane zostają w waszym środowisku. Na życzenie działamy na odizolowanej infrastrukturze. **Q: Z jakimi narzędziami do ewaluacji pracujecie?** Nie zależy nam na konkretnym narzędziu; pracujemy na tym, co już macie: Braintrust, Langfuse, LangSmith, Confident AI, Promptfoo, Arize Phoenix, W&B Weave albo własny zestaw testów w waszym repozytorium. Gdy nic nie ma, pomagamy wybrać, a przy dużej liczbie ewaluacji pokazujemy, gdzie własny hosting platformy open source kosztuje mniej niż SaaS. Zestaw piszemy tak, żeby dało się go przenieść między narzędziami, bo wiązanie punktu odniesienia jakości z jednym dostawcą jest ryzykiem na rynku, który się konsoliduje. **Q: Próbowaliśmy już darmowego narzędzia do ewaluacji. Co dokładacie?** Platformy ewaluacyjne mają darmowe poziomy, więc wielu klientów przychodzi po własnej próbie. Zespoły rzadko blokują się na narzędziu. Blokują się na dwóch rzeczach, których narzędzie nie daje: zestawie testowym, który odzwierciedla to, o co naprawdę pytają użytkownicy, oraz pisemnej definicji dobrze, którą podpisują osoba odpowiedzialna za wynik i inżynierowie. Zaczynamy dokładnie tam, a wybrane przez was narzędzie dalej pracuje pod spodem. **Q: Czy ewaluujecie procesy z agentami, nie tylko pojedyncze odpowiedzi?** Tak. Mierzymy skuteczność całego procesu: udział zadań wykonanych od początku do końca, udział przejęć przez człowieka (jak często ktoś po cichu kończy zadanie), błędy na poziomie kroków w sesjach, turach, wywołaniach narzędzi i podagentach oraz efekt na proces: ile czasu krok z AI zdejmuje z procesu, a ile przenosi na kogoś innego. **Q: Co dzieje się po zleceniu i kto utrzymuje zestaw ewaluacyjny?** Zestaw, kryteria i bramka w CI są wasze, w waszym repozytorium i waszych narzędziach; wasz zespół uruchamia je i rozszerza bez nas. Jeśli wolicie nie utrzymywać tego sami, prowadzimy to jako stałą współpracę: utrzymujemy zestaw, uruchamiamy go po każdej zmianie modelu, promptu albo dostawcy i raportujemy regresję wobec waszego punktu odniesienia. Ta współpraca idzie obok LLM Observability, które pilnuje tych samych sygnałów jakości w ruchu na żywo. ### Powiązane - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/audyt-kodu-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna --- # Budowa, automatyzacja i modernizacja (anchor 03) **URL:** https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai **Highlight:** Oprogramowanie z AI, sprawdzane przed każdym wdrożeniem > Budowa oprogramowania z pomocą AI, automatyzacja procesów i modernizacja systemów legacy. Na końcu każdej z tych praktyk zostaje u was konkret: kod ze sprawdzaniem każdej zmiany, procedura z właścicielem albo system, który znów da się rozwijać. ### Podsumowanie 23Minds buduje, automatyzuje i modernizuje systemy. Klientami są firmy, które stawiają pierwszy system z AI, oraz zespoły, które mają już kod i chcą wdrażać częściej. Budowa oprogramowania obejmuje aplikacje, backendy z agentami i narzędzia wewnętrzne. Kod piszą agenty AI pod nadzorem inżyniera, a każdą zmianę sprawdzają automatyczne kontrole i dwa modele z różnych rodzin. Automatyzacja procesów kończy się spisaną procedurą z właścicielem i rejestrem zmian. Modernizacja systemów legacy wymienia komponenty po kolei, z refaktoryzacją wspieraną przez AI, gdy pełne przepisanie nie wchodzi w grę. Budowa oprogramowania i zrobotyzowana automatyzacja procesów są w zakresie certyfikatu ISO 9001:2015 firmy (DNV, nr 10000439701-MSC-RvA-POL, ważny do 3.03.2027). ### Dla kogo to jest - Właściciele i dyrektorzy firm, które nie mają jeszcze nic z AI i szukają wykonawcy pierwszego systemu, a nie doradcy - Zespoły produktowe i inżynierskie, które budują produkt z funkcjami AI albo dokładają je do istniejącego - Dyrektorzy operacyjni i finansowi, których proces ma działać tak samo po odejściu jedynej osoby, która go zna - CTO z systemem legacy, który blokuje plan produktowy, gdy pełne przepisanie nie wchodzi w grę ### Problemy, które rozwiązujemy - Firma chce zbudować pierwszy system z AI i nie wie, od jakiego zakresu zacząć ani komu to powierzyć - Prototyp z AI działa na demo, a na produkcji nikt nie chce wziąć za niego odpowiedzialności - Proces w back office działa ręcznie i z pamięci; nikt nie umie spisać, co się dzieje przy wyjątku - System legacy blokuje plan produktowy, a pełne przepisanie jest poza budżetem ### Praktyki pod tym anchorem - Budowa oprogramowania z AI - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/budowa-oprogramowania-z-ai - Automatyzacja procesów - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/automatyzacja-procesow - Modernizacja systemów legacy - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/modernizacja-systemow-legacy ### FAQ **Q: Czym budowa oprogramowania z AI różni się od zwykłego software house'u?** Rezultat jest ten sam: aplikacja na produkcji. Różni się proces. Kod piszą agenty AI pod nadzorem inżyniera, testy i pierwszy przegląd kodu też idą z AI. Każda zmiana przechodzi automatyczne kontrole (typecheck, lint, build, przegląd kodu), dostaje podgląd do kliknięcia i przegląd drugiego inżyniera. Dostajecie kod, pipeline dostarczania i ślad każdej decyzji w repozytorium. **Q: Budujecie agenty od projektu do produkcji?** Tak. Projektujemy architekturę agenta (jeden krok, wiele kroków, wielu agentów), budujemy infrastrukturę wokół niego (pamięć, wyszukiwanie, wywołania narzędzi, observability), spinamy go z waszymi systemami i wdrażamy na produkcję. Razem z nim oddajemy instrukcje na wypadek awarii (runbooki) dla osób na dyżurze. **Q: Jakie procesy automatyzujecie?** Takie, które dziś prowadzi ręcznie jedna osoba: obieg faktur, obsługa zamówień, onboarding, kontrole zgodności, raportowanie. Budujemy na narzędziach, które wasz zespół obsłuży sam (UiPath, Power Automate, n8n albo zwykłe skrypty). Oddajemy automatyzację jako spisaną procedurę z właścicielem, obsługą wyjątków, historią wersji i terminem przeglądu. Zrobotyzowana automatyzacja procesów biznesowych jest w zakresie naszego certyfikatu ISO 9001. **Q: Da się zmodernizować system legacy bez przepisywania go od nowa?** Zwykle tak. Oceniamy system, wyznaczamy komponenty do wymiany i podmieniamy je po kolei (metoda strangler fig), z refaktoryzacją wspieraną przez AI. Stary system pracuje obok nowego, aż przestanie być potrzebny. Zakres i harmonogram wynikają z oceny systemu, którą dostajecie na piśmie przed pierwszą fazą. **Q: W jakich technologiach pracujecie?** Backend: TypeScript, Node, Next.js; Python, FastAPI; Go. Frontend: React, Vue. Dane: Postgres, ClickHouse, pgvector, Pinecone. Infrastruktura: AWS, GCP, Vercel, Fly. Modele: OpenAI, Anthropic, Google i modele open source przez Bedrock albo Together. **Q: Czy AI przyspiesza dostarczanie oprogramowania?** Pomiary się różnią, dlatego mierzymy to na waszym projekcie. W trzech eksperymentach terenowych z udziałem 4 867 programistów w Microsoft, Accenture i firmie z listy Fortune 100 osoby korzystające z GitHub Copilot ukończyły o 26,08% więcej zadań (Cui i współautorzy, Management Science, 2026). W badaniu METR z randomizacją 16 doświadczonych programistów open source pracowało z narzędziami AI o 19% dłużej, choć uczestnicy oceniali, że pracowali o 20% szybciej (lipiec 2025); aktualizacja z lutego 2026 nie pozwoliła jednoznacznie potwierdzić przyspieszenia, bo przedział ufności obejmował zero. Raport DORA 2024 szacował, że wzrost wykorzystania AI o 25% idzie w parze ze spadkiem stabilności dostarczania o 7,2%, a raport DORA 2025, oparty na odpowiedziach prawie 5 000 specjalistów, nadal wiązał szersze wykorzystanie AI z niższą stabilnością przy wyższej przepustowości. Dlatego raport z każdej fazy podaje liczbę zmian wdrożonych na produkcję i liczbę defektów wykrytych po scaleniu w tym samym okresie. --- ## Budowa oprogramowania z AI - Budowa i modernizacja **URL:** https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/budowa-oprogramowania-z-ai **Service type:** Tworzenie oprogramowania na zamówienie **Anchor:** Budowa, automatyzacja i modernizacja (Budowa i modernizacja) > 23Minds buduje aplikacje, narzędzia wewnętrzne i systemy z AI dla firm, które chcą je mieć na produkcji. Kod powstaje z pomocą AI od specyfikacji po testy, a każdą zmianę sprawdzają automatyczne kontrole i dwa modele z różnych rodzin, zanim trafi do was. Zmiany w danych, uprawnieniach, płatnościach i integracjach czyta też inżynier. ### Podsumowanie 23Minds buduje oprogramowanie produkcyjne z pomocą AI: aplikacje webowe, narzędzia wewnętrzne, backendy z agentami i produkty, w których AI jest funkcją. Usługa jest dla firm stawiających pierwszy system oraz dla zespołów, którym brakuje rąk albo doświadczenia przy AI. Każdą zmianę sprawdzają automatyczne kontrole i dwa modele z różnych rodzin, zmiany ryzykowne czyta też inżynier, a raport z fazy pokazuje tempo dostarczania obok defektów po scaleniu. Współpraca zaczyna się od rozmowy wstępnej i pierwszej fazy w stałej cenie: sprintu PoC na waszych danych albo pierwszej fazy budowy, gdy zakres jest znany. Projektowanie i tworzenie aplikacji jest w zakresie certyfikatu ISO 9001:2015 firmy. ### Dla kogo to jest - Właściciele i dyrektorzy firm, które budują pierwszy system z AI i chcą jednego wykonawcy odpowiedzialnego za całość - Zespoły produktowe, które budują produkt z funkcjami AI albo dokładają je do istniejącego - Założyciele z pomysłem na produkt oparty na AI, którym brakuje doświadczonego inżyniera na starcie - Firmy, których plan produktowy przerasta możliwości własnego zespołu inżynierskiego ### Problemy, które rozwiązujemy - Prototyp zbudowany w firmie działa na demo, a nikt nie umie przenieść go na produkcję - Prototyp zbudowany z promptami stoi bez testów, bez śladu przeglądu, bez instrukcji na wypadek awarii i bez właściciela na produkcji - Własny zespół jest obłożony, a plan produktowy przesuwa się co kwartał - Procesy z agentami dobrze wypadają w demo, ale zespół nie ma wzorca, jak prowadzić je na produkcji - Trudno ocenić, ile powinien kosztować projekt, w którym część pracy wykonuje AI ### Co dostajecie - Po sprincie PoC: działający przypadek użycia na staging, kod źródłowy, testy i raport z benchmarku - Po pełnym projekcie: działająca aplikacja na produkcji (webowa, backend z agentami albo narzędzie wewnętrzne) - Kod źródłowy z dokumentacją, testami, konfiguracją wdrożenia i runbookami, czyli instrukcjami na wypadek awarii - Pipeline dostarczania przekazany razem z kodem: bramki w CI, szablon PR, lista kontrolna przeglądu, środowiska podglądu - Infrastruktura jako kod dla produkcji, stagingu i środowisk podglądu - Monitoring i alerty gotowe pod dyżur; sam dyżur prowadzi wasz zespół albo utrzymanie w osobnej umowie - Przekazanie wiedzy waszemu zespołowi: sesje w parach, omówienia, nagrane przekazanie ### Jak pracujemy 1. **1. Rozmowa wstępna i zakres** (Tydzień 0-1): Rozmowa wstępna, definicja problemu, ustalenie zakresu technicznego i propozycja pierwszej fazy w stałej cenie. 2. **2. Ticket, specyfikacja, plan** (Przy każdej zmianie): Każda zmiana zaczyna się od ticketu, potem powstaje pisemna specyfikacja i plan. Bramka: zakres i plan każdej większej zmiany zatwierdzacie wy; drobne poprawki idą w ramach zatwierdzonego planu. 3. **3. Implementacja** (Przy każdej zmianie): Inżynier ustala sposób implementacji i prowadzi agentów AI, którzy piszą kod razem z testami jednostkowymi. Decyduje też, co wymaga poprawy albo odrzucenia. Bramka: każda zmiana zachowania programu ma test, który je sprawdza. Bez takiego testu zmiana nie idzie dalej. 4. **4. Automatyczne kontrole** (Przy każdym commicie): Na każdej gałęzi działają automatyczne kontrole: typecheck, lint, testy, build oraz sprawdzenie zależności i sekretów. Potem kod przeglądają niezależnie dwa modele z różnych rodzin. Bramka: problemy o wadze krytycznej i wysokiej trzeba usunąć przed kolejnym etapem. Te same kryteria obowiązują dla kodu pisanego przez AI i przez człowieka. 5. **5. PR, podgląd i przegląd zmian ryzykownych** (Przy każdej zmianie): Do każdego PR-a powstaje środowisko podglądu z działającą zmianą, a wyniki obu przeglądów zostają w PR-ze. Bramka: przed wdrożeniem inżynier czyta linijka po linijce każdą zmianę dotyczącą migracji i danych, uwierzytelniania i uprawnień, płatności albo integracji z waszymi systemami. 6. **6. Scalenie i sprawdzenie na produkcji** (Przy każdym wydaniu): Po wdrożeniu sprawdzamy zmianę w działającym systemie i logi z pierwszych minut po uruchomieniu. Bramka: gdy sprawdzenie wykaże problem, najpierw przywracamy działanie według planu wycofania ustalonego przed wdrożeniem, a dopiero potem poprawiamy. Zmiana jest skończona, gdy działa na produkcji i przeszła wasz odbiór. 7. **7. Przygotowanie do startu i przekazanie** (Ostatnie 2-4 tygodnie): Przegląd gotowości produkcyjnej, testy obciążeniowe, monitoring i alerty, szkolenie dyżuru, sesje w parach i udokumentowane przekazanie. Dalsze utrzymanie opcjonalnie w ramach praktyki utrzymania aplikacji. ### FAQ **Q: Jak szybko możecie zacząć?** Od rozmowy wstępnej do pierwszego sprintu zwykle mijają 2-3 tygodnie. Przy jasnym zakresie i wolnych mocach potrafimy zacząć w tydzień. **Q: Czy tempo, które daje AI, kosztuje nas stabilność?** Na taką wymianę się nie zgadzamy i po to jest ten pipeline. W raporcie z każdej fazy pokazujemy obok siebie, ile zmian trafiło na produkcję i ile defektów wyszło po scaleniu. Gdy defektów przybywa, zaciskamy bramki. Nie traktujemy tego jako ceny za tempo. Dane branżowe pokazują ten kompromis: raport DORA 2024 szacował, że wzrost wykorzystania AI o 25% idzie w parze ze spadkiem stabilności dostarczania o 7,2%, a raport DORA 2025, oparty na odpowiedziach prawie 5 000 specjalistów, nadal pokazywał spadek stabilności przy rosnącej przepustowości. Wyniki dotyczące tempa się różnią: w trzech eksperymentach terenowych z 4 867 programistami osoby korzystające z GitHub Copilot ukończyły o 26,08% więcej zadań (Cui i współautorzy, Management Science, 2026), a w badaniu METR z 2025 roku doświadczeni programiści open source pracowali z narzędziami AI o 19% dłużej. **Q: Stała cena czy rozliczenie godzinowe?** Stała cena za fazę. Pierwszą fazą jest sprint PoC, gdy zakres wymaga sprawdzenia na waszych danych; cena pakietu jest w cenniku na tej stronie. Przy znanym zakresie zaczynamy od pierwszej fazy budowy w stałej cenie. Kolejne fazy wyceniamy osobno, na podstawie tego, czego nauczyła poprzednia. **Q: Kto jest właścicielem kodu?** Kod projektu należy do was. Biblioteki i wzorce, które powstały u nas przed projektem, zostają nasze, a wy dostajecie prawo do ich używania w tym projekcie. Zasady są w umowie; na sam projekt podpisujemy wzajemne NDA. **Q: Czy pracujemy z tymi samymi inżynierami przez cały projekt?** Tak. Skład zespołu jest stały od startu do przekazania. Nie wymieniamy inżynierów w trakcie, chyba że sami o to poprosicie. **Q: Budujecie systemy z AI w środku, czy tylko zwykłe aplikacje?** Jedno i drugie. Aplikacje bez funkcji AI: panel operacyjny, portal klienta, integracja systemów. Systemy z AI w środku: backendy z agentami (jeden krok, wiele kroków, wielu agentów), RAG, API oparte na modelach językowych, wyszukiwanie wektorowe. Te drugie oddajemy dodatkowo z ewaluacją jakości odpowiedzi. ### Powiązane - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/modernizacja-systemow-legacy - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai --- ## Automatyzacja procesów - Budowa i modernizacja **URL:** https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/automatyzacja-procesow **Service type:** Automatyzacja procesów biznesowych **Anchor:** Budowa, automatyzacja i modernizacja (Budowa i modernizacja) > 23Minds automatyzuje procesy biznesowe i przekazuje waszemu zespołowi działający automat, procedurę obsługi i rejestr zmian. Zrobotyzowana automatyzacja procesów biznesowych jest w zakresie certyfikatu ISO 9001 firmy, więc automat powstaje w tym samym systemie jakości co reszta jej projektów. ### Podsumowanie 23Minds automatyzuje procesy biznesowe dla zespołów operacyjnych, finansowych i administracyjnych, które po przekazaniu muszą tę automatyzację rozumieć, zmieniać i kontrolować bez 23Minds. Każda automatyzacja wychodzi z kompletem, jakiego wymaga system jakości: opisem procesu, procedurą krok po kroku, obsługą wyjątków, nazwanym właścicielem, historią wersji i cyklem przeglądu. Taki komplet pomaga przygotować automat do audytu wewnętrznego i do audytu klienta. Zrobotyzowana automatyzacja procesów biznesowych w systemach informatycznych jest w zakresie certyfikatu ISO 9001:2015 firmy (DNV Business Assurance, nr 10000439701-MSC-RvA-POL). Automat działa na narzędziach, które wasz zespół potrafi obsłużyć (UiPath, Power Automate, n8n albo zwykłe skrypty). Tam, gdzie reguły nie wystarczą, bo trzeba zinterpretować treść dokumentu, maila albo transkryptu, automat dostaje krok oparty na modelu językowym z progiem pewności. Współpraca zaczyna się od pakietu projektowego, czyli faz mapowania i projektu: mapa jednego procesu, model ROI i decyzja, czy budować, czy kupić. ### Dla kogo to jest - Szefowie operacji, których proces działa z pamięci jednej osoby i ma działać tak samo, gdy tej osoby nie ma - Dyrektorzy finansowi i administracyjni, których proces musi przejść audyt: kto zmienił co, kiedy i za czyją zgodą - Pełnomocnicy jakości w firmach z certyfikatem ISO 9001, którzy potrzebują automatyzacji opisanej jak każda inna procedura - Zespoły, które odziedziczyły automatyzację po dostawcy albo po byłym koledze i nikt nie umie powiedzieć, co ona robi ### Problemy, które rozwiązujemy - Proces żyje w głowie jednej osoby i w arkuszu; nikt nie umie spisać, co się dzieje, gdy przychodzi wyjątek - Automatyzacja kupiona u dostawcy działa jak czarna skrzynka: bez dokumentacji, bez historii wersji, bez nikogo u was, kto mógłby ją zmienić - System jakości wymaga procedury i właściciela procesu, a bot nie ma ani jednego, ani drugiego - Każda zmiana w systemie źródłowym psuje automatyzację, a naprawa wymaga dostawcy, bo wasz zespół nie ma ani instrukcji, ani dostępu do konfiguracji - Niedokończone skrypty i prompty pracują na produkcji bez testu, bez logu i bez zapisu, kto zatwierdził ostatnią zmianę ### Co dostajecie - Opis procesu w stanie obecnym i docelowym: kroki, decyzje, ścieżki wyjątków i systemy, których dotyka każdy krok - Działająca automatyzacja w waszym środowisku, na narzędziach, które wasz zespół obsłuży (UiPath, Power Automate, n8n albo zwykłe skrypty) - Procedura z nazwanym właścicielem, rejestr zmian, historia wersji i zapis zatwierdzenia każdej zmiany - Obsługa wyjątków z przekazaniem sprawy do wskazanej osoby oraz log, który pokazuje, co automat zrobił i dlaczego - Właściciel i zastępca uczą się obsługi automatu, a harmonogram przeglądów mówi, co sprawdzać, jak często i kto podpisuje - Opcjonalnie: okresowe przeglądy w ramach utrzymania aplikacji ### Jak pracujemy 1. **1. Mapowanie procesu** (Tydzień 1-2): Spisujemy z waszym zespołem obecny przebieg procesu, razem z tym, co już działa automatycznie: kroki, decyzje, wyjątki, systemy. Stan docelowy uzgadniamy z właścicielem procesu. Bramka: właściciel podpisuje opis procesu. 2. **2. Projekt i dobór narzędzi** (Tydzień 2-3): Dla każdego kroku wybieramy narzędzie: RPA, skrypt albo krok oparty na modelu tam, gdzie trzeba zinterpretować treść. Projektujemy ścieżki wyjątków i log. Bramka: pisemny projekt z listą kroków, które zostają ręczne, oraz z powodem przy każdym z nich. 3. **3. Budowa i testy** (W projekcie, tygodnie 3-6): Budujemy w waszym środowisku i testujemy na prawdziwych sprawach, razem z wyjątkami. Każda zmiana ma numer wersji i osobę, która ją zatwierdziła. 4. **4. Uruchomienie kontrolowane** (W projekcie, tygodnie 6-8): Automatyzacja pracuje równolegle z procesem ręcznym, a wyniki porównujemy sprawa po sprawie. Po drodze mierzymy udział wyjątków. Przełączamy, gdy właściciel przyjmie wynik. 5. **5. Przekazanie i cykl przeglądu** (W projekcie, tygodnie 8-9): Oddajemy procedurę, szkolimy właściciela i zastępcę, ustalamy termin pierwszego przeglądu i osobę, która go podpisuje. ### FAQ **Q: Co w praktyce znaczy udokumentowany proces?** Trzy dokumenty, każdy z właścicielem: opis procesu (co się dzieje i w jakich systemach), procedura (jak automat wykonuje proces i co robi człowiek, gdy automat stanie) oraz rejestr zmian (co się zmieniło, kiedy i za czyją zgodą). To ten sam kształt, jaki ma procedura w systemie jakości ISO 9001, więc wpisuje się w istniejący system bez przepisywania. **Q: Dlaczego ISO 9001 ma znaczenie przy automatyzacji?** Zrobotyzowana automatyzacja procesów biznesowych jest w zakresie naszego certyfikatu ISO 9001:2015. Budujemy więc automatyzacje wewnątrz systemu zarządzania jakością audytowanego przez DNV: udokumentowane, wersjonowane, przeglądane. Dla was oznacza to automat z właścicielem, historią wersji i zapisem zatwierdzeń, czyli z tym, o co pyta audytor wewnętrzny i audytor waszego klienta. **Q: Na jakich narzędziach pracujecie?** Na takich, które wasz zespół obsłuży po przekazaniu i które pasują do procesu. UiPath i Power Automate tam, gdzie macie już licencje; n8n albo zwykłe skrypty tam, gdzie prostsze narzędzie wystarczy. Gdy krok wymaga zinterpretowania dokumentu, maila albo transkryptu, dokładamy krok oparty na modelu z progiem pewności i ścieżką do człowieka poniżej progu. Automat działa w waszym środowisku, na kontach i licencjach, które kontrolujecie. **Q: Przejmiecie automatyzację, którą zbudował ktoś inny?** Tak. Zaczynamy od spisania, co ona dziś robi. Często jest to pierwszy taki opis. Potem decydujemy krok po kroku: zostawić, przebudować albo wygasić. Na końcu dostajecie ten sam komplet dokumentów co przy nowej automatyzacji. **Q: Kto utrzymuje automatyzację po przekazaniu?** Za proces i przeglądy odpowiada wasz właściciel procesu, według procedury. Szkolimy go razem z zastępcą i ustalamy cykl przeglądu z datą i podpisem. Naprawy, aktualizacje narzędzi i zmiany w integracjach robi wasz zespół techniczny albo 23Minds w ramach utrzymania aplikacji. Dokumentacja jest wasza w obu wariantach. **Q: Jak decydujecie, co zautomatyzować, a co zostawić ręczne?** Najpierw automatyzujemy kroki stabilne i oparte na regułach. Decyzje wymagające oceny zostają przy człowieku, który dostaje lepsze wejście do automatu, na przykład kolejkę albo listę kontrolną. Tam, gdzie model przygotowuje wynik, poniżej progu pewności sprawa i tak trafia do osoby. Zapisujemy, który krok jest którym i dlaczego, żeby następny przegląd mógł wrócić do tej decyzji zamiast zgadywać. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm --- ## Modernizacja systemów legacy - Budowa i modernizacja **URL:** https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/modernizacja-systemow-legacy **Service type:** Modernizacja starszych systemów **Anchor:** Budowa, automatyzacja i modernizacja (Budowa i modernizacja) > 23Minds ocenia system legacy i modernizuje go etapami. Każda faza ma własny zakres i budżet, nowe komponenty wchodzą na produkcję obok starego systemu, a refaktoryzację wspiera AI pod przeglądem inżyniera. ### Podsumowanie 23Minds modernizuje systemy legacy, które blokują rozwój produktu. Usługa zaczyna się od oceny systemu: architektura, zależności, punkty ryzyka. Potem powstaje mapa drogowa w modelu strangler fig, czyli plan wymiany komponentów po kolei, z budżetem na każdą fazę. Nowe komponenty wchodzą na produkcję obok starego systemu za warstwą przekierowań, a stara ścieżka jest wygaszana dopiero po ustabilizowaniu nowej. Refaktoryzację przyspiesza AI, a każdą zmianę sprawdza inżynier. Typowe systemy: monolity w PHP, Perlu i starszym .NET, Java EE, aplikacje z HTML generowanym na serwerze i interfejsem na jQuery, nietypowany JavaScript, stary Python. ### Dla kogo to jest - CTO, których plan produktowy blokuje system, którego zespół boi się dotknąć - Szefowie inżynierii, którzy porównują koszt modernizacji z kosztem nowego systemu i z kosztem zostawienia wszystkiego po staremu - Firmy, w których nikt z obecnego zespołu nie chce ani nie umie utrzymywać kodu pierwszego produktu - Spółki po przejęciu, które muszą połączyć własny system z wyraźnie starszym systemem przejętej firmy ### Problemy, które rozwiązujemy - System legacy nie ma testów; każda zmiana to ryzyko dla produkcji - Dokumentacji nie ma albo jest nieaktualna, a wiedza o systemie siedzi w głowach jednej lub dwóch osób - Pełne przepisanie jest za drogie, a każdy kwartał ze starym systemem kosztuje coraz więcej - Trudno zatrudniać, bo nowi inżynierowie nie chcą utrzymywać starej technologii ### Co dostajecie - Po ocenie: raport o systemie (architektura, zależności, punkty ryzyka, warianty modernizacji) i mapa drogowa z fazami ułożonymi według ryzyka i budżetem na każdą - Po pracach modernizacyjnych: zmodernizowane komponenty działające na produkcji obok systemu legacy, z zapisem przełączenia każdego z nich - Testy i dokumentacja granicy między nowym a starym kodem - Przekazanie wiedzy waszemu zespołowi: sesje w parach, spisana architektura ### Jak pracujemy 1. **1. Ocena systemu** (Tydzień 1-3): Czytamy kod pod NDA. Rozmawiamy z inżynierami, którzy go utrzymują. Uruchamiamy analizę statyczną i mapujemy zależności. 2. **2. Mapa drogowa** (Tydzień 3-4): Wyznaczamy granice komponentów do wymiany. Układamy fazy według ryzyka i tego, co odblokują w planie. Każda faza dostaje budżet. 3. **3. Sprinty modernizacyjne** (Tydzień 4 i dalej): Wymieniamy komponenty faza po fazie. Każda faza wchodzi za warstwą przekierowań, która prowadzi ruch do starej albo nowej ścieżki. 4. **4. Wygaszanie starej ścieżki** (Po każdej fazie): Gdy komponent jest w całości wymieniony i stabilny, kasujemy starą ścieżkę z repozytorium. Powtarzamy, aż system legacy zniknie. ### FAQ **Q: Naprawdę da się modernizować po kawałku, bez wielkiego przepisania?** Tak, to standardowy wzorzec strangler fig. Budujemy warstwę przekierowań, która prowadzi ruch do starej albo nowej ścieżki, wymieniamy jeden komponent naraz i wygaszamy stary kod dopiero, gdy nowy jest stabilny na produkcji. Pełne przepisanie zostawiamy na przypadki, w których wymiana po kawałku jest naprawdę niemożliwa. **Q: Co konkretnie robi AI przy refaktoryzacji?** Przyspiesza żmudne części: czytanie nieznanego kodu, generowanie testów dla kodu, który ich nie ma, przenoszenie między idiomami (na przykład z callbacków na async/await), proponowanie refaktoryzacji do przeglądu. Ocena inżynierska zostaje po stronie naszego zespołu, a praca masowa idzie szybciej. **Q: W jakich technologiach legacy pracujecie?** PHP (Symfony 1.x, własne frameworki), starszy .NET (Framework 4.x, ASP.NET WebForms i MVC), Java EE i Spring Boot sprzed wersji 2, aplikacje z HTML generowanym na serwerze i interfejsem na jQuery, nietypowany Node.js, Python 2 i wczesny Python 3. **Q: Co, jeśli nasz kod nie ma żadnych testów?** To częsty punkt startu. Pierwsza faza modernizacji zwykle obejmuje zestaw testów obecnego zachowania wokół komponentów, które będziemy wymieniać: generowane z pomocą AI, przeglądane przez naszych inżynierów. Testy powstają przed refaktoryzacją, zawsze. **Q: Czy stary system może działać w trakcie modernizacji?** Tak, o to chodzi w strangler fig. System legacy dalej obsługuje ruch produkcyjny, a nowe komponenty wchodzą za warstwą przekierowań. Każdy komponent ma plan przełączenia i powrotu do starej ścieżki, gdyby coś poszło nie tak. ### Powiązane - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/budowa-oprogramowania-z-ai - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/pokrycie-testowe - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai --- # Utrzymanie, pomiary i optymalizacja (anchor 04) **URL:** https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai **Highlight:** Telemetria i LLM Observability > Utrzymanie systemów AI pomaga wykrywać spadki jakości odpowiedzi, wyjaśniać wzrost kosztów i przygotowywać migracje modeli. Obejmuje observability, telemetrię, audyt kosztów i bieżące utrzymanie aplikacji korzystających z modeli. ### Podsumowanie 23Minds utrzymuje AI na produkcji dla zespołów, które chcą kontrolować jakość odpowiedzi, koszty i migracje modeli, gdy zmieniają się dane, ruch i dostawcy. Obszar obejmuje LLM Observability (tracing, procesy ewaluacji, wykrywanie dryfu), telemetrię i analitykę produktów z AI (wskaźniki jakości, kosztów i czasu odpowiedzi oraz powiadomienia o przekroczeniu progów), audyt kosztów i doboru modeli oraz bieżące utrzymanie aplikacji korzystających z modeli. Audyt kosztów porównuje ceny modeli z rzeczywistym zużyciem i wymaganą jakością odpowiedzi: cache promptów, dobór tańszych modeli tam, gdzie testy potwierdzają jakość, kompresja promptów. Raport z optymalizacji porównuje koszty i jakość odpowiedzi przed zmianami i po nich. Punktem wyjścia są cenniki dostawców (stan na 25.09.2026). W Anthropic odczyt z cache promptów kosztuje 0,1 podstawowej ceny tokenów wejściowych, a zapis na pięć minut 1,25 tej ceny. OpenAI nalicza za tokeny z cache w modelach GPT-5.6 i nowszych także 0,1 ceny tokenów wejściowych, a Google w Gemini API podaje dla bieżących modeli 10% tej ceny. Kalendarz utrzymania wyznaczają wycofania modeli: Anthropic ogłasza je co najmniej 60 dni przed wyłączeniem modelu udostępnionego publicznie, OpenAI co najmniej 6 miesięcy przed wyłączeniem modelu ogólnie dostępnego. ### Dla kogo to jest - Zespoły inżynierskie z funkcjami opartymi na modelach językowych na produkcji i nieprzewidywalnymi kosztami - Szefowie produktu, którzy nie umieją powiedzieć, czy funkcja AI naprawdę działa dla użytkowników - Dyrektorzy finansowi, którzy pytają, dlaczego rachunek za modele językowe ciągle rośnie - Zespoły DevOps i SRE, które odpowiadają za aplikacje korzystające z modeli na dyżurze ### Problemy, które rozwiązujemy - Wydatki na modele językowe rosną szybciej niż ruch i nikt nie umie powiedzieć dlaczego - Nie ma sygnału, czy zmiany promptów poprawiły produkt, czy go popsuły - Dostawca wycofał model, a zespół nie ma planu migracji - Skarg klientów na jakość AI nie da się powiązać z konkretnym zachowaniem systemu na produkcji ### Praktyki pod tym anchorem - LLM Observability - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability - Telemetria i analityka produktu - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/analityka-produktu-ai - Optymalizacja kosztów modeli językowych - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm - Utrzymanie aplikacji - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai ### FAQ **Q: Jakie oszczędności może wskazać audyt kosztów modeli językowych?** Tyle, ile wyjdzie z pomiaru u was; nie obiecujemy procentu z góry. Oszczędności biorą się z czterech mechanizmów: wyższego udziału trafień w cache promptów, doboru tańszych modeli do zadań, w których testy potwierdzają wymaganą jakość, kompresji promptów i usunięcia zbędnych ponowień. Pakiet audytu kończy się pisemnym raportem ze zmierzonym efektem trzech wdrożonych zmian. W Anthropic i w najnowszych modelach OpenAI odczyt z cache kosztuje jedną dziesiątą podstawowej ceny tokenów wejściowych. **Q: Jakiego stosu observability używacie?** Opartego na OpenTelemetry tam, gdzie się da. Integrujemy się z Datadog, Honeycomb, Grafaną, PostHogiem i narzędziami do observability modeli językowych (Langfuse, Arize, Helicone), zależnie od tego, co już macie. Konwencje semantyczne OpenTelemetry dla generatywnej AI od wersji semconv 1.42.0 (12.06.2026) mają osobne repozytorium i nadal status Development, więc nazwy atrybutów mogą się zmieniać między wydaniami. **Q: Jak mierzycie, czy zmiany promptów poprawiły produkt?** Porównujemy odpowiedzi przed zmianą promptu i po niej na tym samym zestawie testowym, według kryteriów zaprojektowanych pod wasz produkt. Gdy wskaźnik, który ma znaczenie, spada, uruchamia się alert o regresji. Jakość odpowiedzi modelu może się zmienić, nawet gdy nie zmieniacie aplikacji: Chen, Zaharia i Zou zmierzyli, że skuteczność GPT-4 w rozpoznawaniu liczb pierwszych spadła z 84% w marcu 2023 do 51% w czerwcu 2023. **Q: Czy obsługujecie migracje, gdy dostawca wycofuje model?** Tak. Migracja między wersjami modelu albo między dostawcami to standardowe zlecenie utrzymaniowe: ponownie ustalamy punkt odniesienia w ewaluacji, uruchamiamy testy regresji, dostosowujemy prompty do nowego modelu i porównujemy jakość odpowiedzi oraz czas ich uzyskania przed migracją i po niej. Zasady dostawców: Anthropic ogłasza wycofanie modelu udostępnionego publicznie co najmniej 60 dni przed jego wyłączeniem. OpenAI daje co najmniej 6 miesięcy dla modeli ogólnie dostępnych i co najmniej 3 miesiące dla wariantów wyspecjalizowanych, a Google podaje daty wyłączenia jako najwcześniejsze możliwe. W praktyce Anthropic wycofał między październikiem 2025 a sierpniem 2026 dziewięć wersji modeli w sześciu terminach, z wyprzedzeniem od 60 do 189 dni. **Q: Utrzymanie to stała współpraca czy zlecenie o stałym zakresie?** Oba warianty. Stała współpraca pasuje zespołom z funkcjami AI, które ciągle pracują na produkcji. Zlecenia o stałym zakresie (migracja dostawcy, audyt kosztów, konfiguracja ewaluacji) pasują zespołom z konkretną potrzebą. --- ## LLM Observability - Utrzymanie i pomiary **URL:** https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability **Service type:** Observability systemów LLM **Anchor:** Utrzymanie, pomiary i optymalizacja (Utrzymanie i pomiary) > LLM Observability pomaga ustalić, gdzie w systemie opartym na modelach językowych powstają błędy odpowiedzi, opóźnienia i koszty oraz czy zmiany promptów poprawiają jakość. Tracing, procesy ewaluacji i wykrywanie dryfu, dla systemów działających i tuż przed startem. ### Podsumowanie 23Minds wdraża observability modeli językowych w systemach, które działają na produkcji albo są przed startem. Usługa wdraża tracing na elementach, które system naprawdę ma: w pakiecie startowym na poziomie żądań, a w projekcie także na sesjach, turach, krokach, wywołaniach narzędzi i podagentach. Buduje procesy ewaluacji, które oceniają nowe wersje promptów i modeli na waszych zestawach testowych, a gdy zestawu nie ma, buduje go od zera. Ustawia wykrywanie dryfu i wpina sygnały w wasz stos observability, istniejący albo dobrany z wami. Zestaw testowy zostaje u was jako bramka w CI i monitor produkcji, a w stałej współpracy jest utrzymywany i rozszerzany po każdej zmianie modelu albo promptu. Podstawa to OpenTelemetry tam, gdzie się da; obsługiwane narzędzia: Datadog, Honeycomb, Grafana, Langfuse, Arize, Helicone, Braintrust, LangSmith, W&B Weave, Confident AI, Galileo. ### Dla kogo to jest - Zespoły inżynierskie, których funkcje oparte na modelach działają na ślepo, bez wglądu w to, co się dzieje - Zespoły z agentami wielokrokowymi, którym logi nie pozwalają wskazać, w którym wywołaniu narzędzia powstał błąd - Szefowie produktu, którzy potrzebują porównania jakości kolejnych wersji promptów - Zespoły SRE, które odpowiadają za aplikacje korzystające z modeli na dyżurze - Liderzy inżynierii AI, którzy chcą rozwijać prompty na podstawie wyników ewaluacji ### Problemy, które rozwiązujemy - Przebieg agenta pada i nikt nie umie odtworzyć, który krok, wywołanie narzędzia albo podagent go zepsuł - Zmiany promptów i modeli wchodzą bez pomiaru; regresje jakości są niewidoczne - Audyt dał kiedyś dobry zestaw testowy, który zestarzał się w tygodniu zmiany modelu - Opóźnienie P99 podwaja się z dnia na dzień i nikt nie umie wskazać przyczyny - Dostawca zwraca złą odpowiedź, a nie ma logu żądania, od którego dałoby się zacząć debugowanie ### Co dostajecie - Tracing elementów systemu (w pakiecie: żądania; w projekcie także sesje, tury, kroki, wywołania narzędzi, podagenci) z promptem, odpowiedzią, opóźnieniem, kosztem i wersją przy każdym wywołaniu modelu oraz danymi zbiorczymi przy krokach i sesjach - Proces ewaluacji na waszych zestawach testowych i alerty o regresji wpięte w CI - Zestaw testowy (istniejący albo zbudowany od zera) przekazany jako bramka scalania w CI i monitor produkcji na tych samych kryteriach, z procedurą rozszerzania po każdej zmianie modelu albo promptu - Wykrywanie dryfu na wyjściach: dryf znaczeniowy, dryf opóźnienia, dryf kosztu - Dashboardy: jakość dla każdej funkcji, koszt dla każdej funkcji, zachowania użytkowników - Runbooki dla zespołu dyżurnego: od alertu przez ślad do kroku, który zawiódł, z listą pytań do sprawdzenia w tej kolejności ### Jak pracujemy 1. **1. Rozpoznanie stosu** (Tydzień 1): Mapujemy obecne wywołania modeli i agentów w waszym kodzie. Inwentaryzujemy funkcje, prompty, dostawców, istniejące zestawy testowe i narzędzia observability. Sprawdzamy, jakie logi daje dostawca i jakich danych brakuje. Ustalamy zakres zapisu, maskowanie danych, dostęp i okres przechowywania śladów. 2. **2. Instrumentacja** (Tydzień 2-3): Obejmujemy tracingiem sesje, tury, kroki, wywołania narzędzi i podagentów. Kierujemy sygnały do wybranego backendu i sprawdzamy, czy każdy przebieg jest widoczny od początku do końca. 3. **3. Procesy ewaluacji i bramka w CI** (Tydzień 3-4): Budujemy zestawy testowe dla każdej funkcji z prawdziwego ruchu i z wcześniejszych ustaleń ewaluacji. Wpinamy przebiegi ewaluacji w CI jako bramkę scalania, a te same kryteria z osobno ustawionymi progami jako monitor produkcji. 4. **4. Szkolenie zespołu dyżurnego i przekazanie** (Tydzień 4): Przechodzimy z zespołem dyżurnym dashboardy, runbooki i scenariusze incydentów. Przekazujemy zestaw testowy jako wasz zasób, w waszym repozytorium. 5. **5. Stała współpraca (opcjonalnie)** (Ciągle): Rozszerzamy zestaw testowy i uruchamiamy regresję po każdej zmianie modelu albo promptu, a potem raportujemy, co się ruszyło i dlaczego. ### FAQ **Q: Który backend do observability albo ewaluacji polecacie?** Zależy od tego, co już macie. Jeśli używacie Datadog albo Honeycomb, rozszerzamy je. Jeśli wolicie narzędzie do modeli językowych: Langfuse, Arize, Helicone, Braintrust, LangSmith, W&B Weave, Confident AI, Galileo. Nie jesteśmy związani z żadnym, pomagamy wybrać pod wasz wolumen i granice danych, a powyżej pewnej liczby żądań liczymy, kiedy własny hosting (Langfuse, Phoenix) wychodzi taniej niż SaaS. **Q: Co, jeśli dostawca narzędzia do ewaluacji zostanie przejęty, zamknięty albo zmieni profil?** Na tym rynku to się zdarza i dlatego nie budujemy waszej praktyki na jednym dostawcy. Zestawy testowe, definicje oceny i ślady zostają w przenośnej formie w waszym repozytorium, a instrumentację robimy przez OpenTelemetry tam, gdzie backend na to pozwala. Platformy się konsolidują; kompetencja i wasze zestawy testowe zostają wasze, więc migracja to przeniesienie konfiguracji, a nie budowa od nowa. **Q: Czy da się obserwować wywołania modeli bez zmian w kodzie aplikacji?** Częściowo. W rozpoznaniu sprawdzamy, jakie logi żądań daje wasz dostawca i czego w nich brakuje. Do observability klasy produkcyjnej (kontekst śladu, przypisanie do użytkownika, przypisanie kosztu, struktura kroków agenta) zwykle owijamy wywołania cienką warstwą SDK. **Q: Czym jest proces ewaluacji?** Sposobem uruchamiania testów i oceny wyników dla wyjść modeli i agentów. Zestaw testowy definiuje, jak wygląda dobra odpowiedź; proces ewaluacji ocenia nowe wersje promptów i modeli na tym zestawie; CI blokuje scalenie, gdy jakość spada, a te same kryteria z osobnymi progami działają jako monitor produkcji. To standard dla zespołów, które traktują prompty jak kod produkcyjny. **Q: Jak dbacie o prywatność danych w śladach?** Przed uruchomieniem tracingu ustalamy z waszym zespołem bezpieczeństwa, co zapisujemy, co maskujemy, kto ma dostęp i jak długo ślady są przechowywane. Tracing usuwa dane osobowe, zanim logi opuszczą waszą infrastrukturę, maskuje fragmenty promptów albo przechowuje pełne prompty tylko na odizolowanej infrastrukturze. **Q: Ile to kosztuje miesięcznie w utrzymaniu?** Trzy osobne pozycje. Koszt backendu do tracingu zależy od wolumenu żądań i narzędzia; własny hosting Langfuse nie ma kosztu licencji, ale wymaga utrzymania. Koszt stałej współpracy jest w cenniku na tej stronie, według poziomu. Dyżur i obsługa incydentów po naszej stronie to osobne uzgodnienie. Oba warianty backendu liczymy w fazie rozpoznania na waszym wolumenie, zanim cokolwiek wybierzecie. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/analityka-produktu-ai - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna --- ## Telemetria i analityka produktu - Utrzymanie i pomiary **URL:** https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/analityka-produktu-ai **Service type:** Telemetria i analityka produktu **Anchor:** Utrzymanie, pomiary i optymalizacja (Utrzymanie i pomiary) > 23Minds wdraża pomiary i raporty pokazujące, jak użytkownicy korzystają z funkcji AI: zdarzenia, dashboardy i powiadomienia, na których produkt, inżynieria i zarząd patrzą na ten sam obraz. ### Podsumowanie 23Minds projektuje i wdraża telemetrię produktową dla produktów z AI. Usługa przekłada pytania o produkt (czy funkcja AI jest naprawdę używana, czy użytkownicy rezygnują na kroku z AI, jak wypadają kolejne wersje promptu) na zdarzenia, dashboardy i powiadomienia. Porównanie wersji z przychodem wymaga danych o przychodzie albo eksperymentu; wtedy wchodzi w zakres. Wynik to taksonomia zdarzeń, rejestrowanie zdarzeń w warstwie web albo backendu (mobilna w projekcie), dashboardy dla produktu, inżynierii i zarządu oraz plan tego, co mierzyć dalej. Pakiet wejściowy obejmuje jeden produkt, jedną warstwę i trzy dashboardy; zasady alertów i kwartalne przeglądy są w zakresie projektu. ### Dla kogo to jest - Szefowie produktu, którym brakuje danych o tym, czy funkcja AI pomaga użytkownikom - Zespoły wzrostu, które testują wersje promptów albo etapowe wdrożenia funkcji AI - Menedżerowie inżynierii, którzy wprowadzają dane do decyzji produktowych - Założyciele produktów opartych na AI bez własnego zespołu analitycznego ### Problemy, które rozwiązujemy - Zespół wypuszcza funkcje AI bez danych o tym, co użytkownicy z nimi robią - Obecna analityka liczy odsłony, a pomija momenty typowe dla AI: edycję promptu, przyjęcie albo odrzucenie odpowiedzi, ponowne generowanie - Każdy zespół ma własny dashboard z innymi liczbami, więc zarząd nie ufa żadnemu - Alerty uruchamiają się na rzeczy, które nikogo nie obchodzą, a prawdziwe problemy przechodzą niezauważone ### Co dostajecie - Taksonomia zdarzeń z momentami typowymi dla AI: prompt wysłany, odpowiedź wyświetlona, przyjęta, odrzucona, wygenerowana ponownie - Rejestrowanie zdarzeń w warstwie web albo backendu (mobilna w zakresie projektu), z wersją promptu i modelu przy każdym zdarzeniu - Trzy dashboardy: produkt (kondycja funkcji), inżynieria (kondycja systemu), zarząd (wskaźniki biznesowe) - W zakresie projektu: zasady alertów, czyli co się uruchamia, kto dostaje powiadomienie, co mówi instrukcja postępowania - Kwartalny przegląd tego, co mierzycie, w miarę jak produkt się zmienia (w stałej współpracy) ### Jak pracujemy 1. **1. Rozpoznanie pytań** (Tydzień 1): Rozmawiamy z produktem, inżynierią i zarządem. Spisujemy pytania, na które każda rola potrzebuje odpowiedzi. Ustalamy priorytety. 2. **2. Taksonomia zdarzeń** (Tydzień 2): Przekładamy pytania na zdarzenia. Definiujemy momenty typowe dla AI. Dokumentujemy właściwości zdarzeń i zasady wersjonowania. 3. **3. Instrumentacja i dashboardy** (Tydzień 2-3): Dodajemy rejestrowanie zdarzeń w wybranej części aplikacji. Budujemy trzy dashboardy. W projekcie ustalamy też zasady alertów. 4. **4. Przekazanie i rytm przeglądów** (Tydzień 3, potem co kwartał): Przechodzimy z każdą grupą odbiorców jej dashboard. W stałej współpracy ustalamy kwartalny przegląd i po trzech miesiącach aktualizujemy listę zdarzeń. ### FAQ **Q: Z jakimi platformami analitycznymi pracujecie?** PostHog, Mixpanel, Amplitude, Segment jako router zdarzeń, Snowplow przy własnym hostingu. Do sygnałów z modeli językowych często dokładamy Langfuse albo Helicone. Wybieramy pod wasz stos, nie z sympatii do dostawcy. **Q: Czy budujecie hurtownię danych?** W ograniczonym zakresie. Wysyłamy zdarzenia analityczne do waszej hurtowni (Snowflake, BigQuery, Redshift, ClickHouse), ale nie budujemy pełnych modeli hurtowni; to osobne zlecenie. **Q: Czym to się różni od LLM Observability?** LLM Observability dotyczy samego wywołania modelu: opóźnienia, kosztu, dryfu odpowiedzi. Telemetria i analityka dotyczy użytkownika i produktu: czy funkcja działa, czy użytkownicy wracają, czy daje przychód. Obie usługi dobrze działają razem. **Q: Czy instrumentujecie też aplikacje mobilne?** Tak. iOS (Swift) i Android (Kotlin), a także React Native i Flutter. Gdy pomiar śledzi użytkownika między aplikacjami, wdrażamy zgodę ATT na iOS. W pakiecie wejściowym jest jedna warstwa; mobilna wchodzi w zakresie projektu. **Q: Jak podchodzicie do prywatności i zgód?** Przed rejestrowaniem zdarzeń ustalamy cel zbierania, zakres danych i okres przechowywania. Zdarzenia, które dotykają danych osobowych, są oznaczone i kierowane zgodnie ze zgodą użytkownika tam, gdzie zgoda jest wymagana. Przegląd prywatności jest częścią fazy instrumentacji. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm - https://23minds.com/pl/uslugi/audyt-i-bezpieczenstwo-kodu-ai/gotowosc-produkcyjna --- ## Optymalizacja kosztów modeli językowych - Utrzymanie i pomiary **URL:** https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm **Service type:** Optymalizacja kosztów systemów LLM **Anchor:** Utrzymanie, pomiary i optymalizacja (Utrzymanie i pomiary) > Audyt kosztów modeli językowych wskazuje, skąd biorą się wydatki. Potem wdraża zmiany, które mogą je obniżyć: konfigurację cache promptów, dobór modeli, kompresję promptów i zasady ponowień. Raport porównuje koszty i wyniki testów jakości przed zmianami i po nich. ### Podsumowanie 23Minds prowadzi audyty kosztów modeli językowych dla zespołów, których rachunek za modele rośnie szybciej niż ruch. Pomiar przypisuje koszt do każdego wywołania, funkcji i segmentu użytkowników. Audyt wskazuje, które zmiany mają największy potencjał oszczędności w waszej aplikacji: konfiguracja cache promptów, dobór tańszych modeli do zadań, w których testy potwierdzają jakość, kompresja promptów, zasady ponowień. Raport porównuje koszty oraz wyniki testów jakości przed zmianami i po nich. Wysokość oszczędności zależy od punktu startu i jest mierzona u was, nie obiecywana z góry. Pakiet wejściowy obejmuje jedną aplikację, rekomendacje i wdrożenie trzech najlepszych szybkich zmian. ### Dla kogo to jest - Zespoły inżynierskie, których miesięczny rachunek za modele językowe urósł ponad plan i dalej rośnie - Dyrektorzy finansowi, którzy pytają, dlaczego wydatki na modele przekraczają budżet - Szefowie inżynierii produktowej, których funkcje AI nie spinają się w rachunku jednostkowym - Firmy przed rundą finansowania, które potrzebują obronić liczby o kosztach AI ### Problemy, które rozwiązujemy - Wydatki na modele językowe rosną szybciej niż ruch użytkowników i nikt nie wie dlaczego - Udział trafień w cache promptów jest niski albo nikt go nie mierzy; każde wywołanie płaci pełną cenę - Wszystkie funkcje idą do najdroższego modelu, niezależnie od wagi zadania - Ponowienia po przejściowych błędach po cichu mnożą rachunek ### Co dostajecie - Dashboard przypisania kosztów: do funkcji, segmentu użytkowników, modelu - Rekomendacje optymalizacji uszeregowane według oszczędności razy nakład - Wdrożenie najlepszych zmian w waszym kodzie: konfiguracja cache, dobór modeli, przebudowa promptów, zasady ponowień - Porównanie wyników testów jakości przed optymalizacją i po niej, na ustalonym zestawie testów - Pisemny raport z audytu z kosztami i jakością przed zmianami i po nich oraz metodą pomiaru ### Jak pracujemy 1. **1. Instrumentacja kosztów** (Tydzień 1-2): Wdrażamy przypisanie kosztu do każdego wywołania. Zbieramy dane przez okres zależny od cyklu pracy aplikacji, zwykle 1-2 tygodnie, żeby obraz kosztów był reprezentatywny. 2. **2. Audyt i rekomendacje** (Tydzień 2): Analizujemy dane o kosztach. Wskazujemy największe możliwości oszczędności. Spisujemy rekomendacje z szacunkiem nakładu. 3. **3. Wdrożenie** (Tydzień 2-3): Wdrażamy najlepsze zmiany. Każda trafia na produkcję po spełnieniu ustalonych kryteriów jakości na zestawie testów; dopiero wtedy liczymy spadek kosztu. 4. **4. Pomiar i raport** (Tydzień 3, w projekcie do 4 tygodni po wdrożeniu): W pakiecie porównujemy okres pomiaru przed audytem z okresem tej samej długości po wdrożeniu i oddajemy raport z metodą pomiaru. W projekcie pomiar trwa 2-4 tygodnie po wdrożeniu. ### FAQ **Q: Jak mierzycie oszczędność?** Porównujemy wydatki na API modeli dla porównywalnych zadań i obciążenia: okres po wdrożeniu z okresem bazowym przed audytem, w pakiecie tej samej długości, w projekcie miesiąc do miesiąca. Wzrost ruchu wyłączamy z porównania, a do tego potrzebujemy danych bazowych o wywołaniach i kosztach. Wynik zależy od punktu startu. Nie obiecujemy procentu z góry. **Q: Czy optymalizacja pogorszy jakość?** Każda optymalizacja jest testowana na ustalonym zestawie testów i kryteriach; wdrażamy tylko zmiany, które spełniają kryteria jakości. Jakość jest ograniczeniem, koszt jest celem optymalizacji. **Q: Które funkcje dostawców mają największe znaczenie?** Audyt wskazuje, które zmiany mają największy potencjał w waszej aplikacji. Typowi kandydaci: cache promptów (Anthropic i OpenAI mają własne mechanizmy), dobór mniejszych modeli do zadań, w których testy potwierdzają jakość, kompresja promptów (usunięcie zbędnego kontekstu) i strojenie ponowień (bez cichych ponowień tam, gdzie błąd się powtórzy). Cenniki rozróżniają koszt odczytu z cache i zapisu do niego. W Anthropic odczyt z cache kosztuje 0,1 podstawowej ceny tokenów wejściowych, zapis na pięć minut 1,25 tej ceny, a zapis na godzinę 2 razy podstawową cenę tokenów wejściowych. OpenAI w modelach GPT-5.6 i nowszych nalicza za tokeny z cache 0,1 ceny tokenów wejściowych, a wpis pozostaje w cache przez 30 minut (stan na 25.09.2026). **Q: Robicie to dla jednego dostawcy czy wielu?** Obu wariantów. Klienci z wieloma dostawcami często mają logikę routingu, która wybiera najtańszy model spełniający wymagania zadania; optymalizujemy ten routing w ramach zlecenia. Klienci z jednym dostawcą optymalizują w granicach jego cennika. **Q: Ile kosztuje zlecenie?** Pakiet wejściowy dla jednej aplikacji ma stałą cenę, podaną w cenniku na tej stronie, bez ukrytych kosztów. Większy zakres wyceniamy po rozmowie wstępnej według wielkości obciążenia. Zwrot z audytu liczymy w raporcie na waszych liczbach, a nie deklarujemy z góry. **Q: Jak Uber ograniczył wydatki na narzędzia AI do kodowania?** CTO Ubera powiedział w kwietniu 2026 serwisowi The Information, że narzędzia AI do kodowania, głównie Claude Code, wyczerpały roczny budżet firmy na AI po kilku miesiącach. W czerwcu 2026 Uber potwierdził agencji Bloomberg, że każde narzędzie AI do kodowania ma limit 1 500 USD na pracownika miesięcznie. W sierpniu 2026 CTO przypisał spadek kosztu tokena lepszemu wykorzystaniu cache promptów, zmianie domyślnego modelu i widoczności kosztów dla inżynierów (Fortune). Przykład dotyczy narzędzi do kodowania. W aplikacji z modelem językowym audyt sprawdza, które funkcje generują koszty, jak wykorzystany jest cache i czy model pasuje do zadania. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/budowa-oprogramowania-z-ai --- ## Utrzymanie aplikacji - Utrzymanie i pomiary **URL:** https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/utrzymanie-aplikacji-ai **Service type:** Utrzymanie aplikacji **Anchor:** Utrzymanie, pomiary i optymalizacja (Utrzymanie i pomiary) > Utrzymanie funkcji AI w aplikacji obejmuje migracje modeli, testy jakości odpowiedzi po zmianach i aktualizacje zależności, żeby ograniczyć ryzyko awarii, gdy zmieniają się modele i ich dostawcy. ### Podsumowanie 23Minds utrzymuje funkcje AI w aplikacjach klientów. Poza zwykłym utrzymaniem obejmuje to testy odpowiedzi po zmianach modeli, promptów i danych wejściowych, migracje, gdy dostawca wycofuje model, oraz monitoring kosztów. Stała współpraca pasuje zespołom z ciągle działającymi funkcjami AI; zlecenie o stałym zakresie pasuje do konkretnego zdarzenia, na przykład jednej migracji. Współpraca zaczyna się od pakietu przejęcia: audytu stanu, inwentaryzacji, planu prac i raportu otwarcia. Wyprzedzenie przy wycofaniu modelu zależy od dostawcy: Anthropic ogłasza je co najmniej 60 dni przed wyłączeniem modelu udostępnionego publicznie, OpenAI co najmniej 6 miesięcy przed wyłączeniem modelu ogólnie dostępnego (stan na 25.09.2026). Utrzymanie aplikacji jest w zakresie certyfikatu ISO 9001:2015 firmy. ### Dla kogo to jest - Zespoły, które potrzebują opieki nad funkcjami AI przed uruchomieniem albo w trakcie działania aplikacji, bez zatrudniania kolejnej osoby - CTO, których zespół zbudował funkcję AI i poszedł dalej; nikt jej dziś nie ma pod opieką - Zespoły produktowe, których dostawcy wycofują modele szybciej, niż zespół nadąża reagować - Firmy, które rozwijają albo utrzymują funkcje AI bez powiększania zespołu ### Problemy, które rozwiązujemy - Dostawca wycofuje model; zespół nie ma planu migracji ani czasu, żeby go napisać - Prompt, który działał na starcie, po pół roku daje gorsze odpowiedzi, bo zmieniły się dane wejściowe - Wersja SDK dostawcy modeli stoi na dniu startu, a poprawki bezpieczeństwa się piętrzą - Koszty rosną na tyle powoli, że nikt tego nie zauważył do przeglądu kwartalnego ### Co dostajecie - W stałej współpracy: miesięczne godziny na migracje modeli, testy jakości odpowiedzi, aktualizacje zależności, monitoring kosztów i wsparcie przy incydentach - Plany migracji dostawców i ich wykonanie, gdy modele są wycofywane, z porównaniem jakości przed i po - Kwartalny przegląd jakości odpowiedzi i korekty promptów, jeśli wyniki wskażą taką potrzebę - Rytm aktualizacji zależności: SDK dostawców, biblioteki observability, frameworki ewaluacji - Kwartalny pisemny raport: co się zmieniło, czego się spodziewać, jakie koszty uwzględnić w następnym kwartale ### Jak pracujemy 1. **1. Przejęcie** (Tydzień 1-2): Sprawdzamy kod i konfigurację. Mapujemy zależności, prompty, konfigurację ewaluacji, observability i procedury dyżuru. Spisujemy luki. 2. **2. Stabilizacja (gdy potrzebna)** (Tydzień 2-4 (jednorazowo)): Zanim ruszy stała współpraca, spłacamy krytyczny dług utrzymaniowy: brakujące ewaluacje, prompty bez nadzoru, przestarzałe SDK. Jednorazowo, w osobnym zakresie. 3. **3. Stała współpraca** (Ciągle): Miesięczne godziny utrzymania, kwartalne spotkania kontrolne, doraźne wsparcie przy zdarzeniach u dostawcy albo incydentach. Zamiast stałej współpracy możliwe jest zlecenie o stałym zakresie, na przykład jedna migracja modelu z własną wyceną. 4. **4. Przegląd kwartalny** (Co kwartał): Pisemny raport: co zmieniliśmy, gdzie pogarszają się wyniki, jakie koszty uwzględnić w następnym kwartale. ### FAQ **Q: Stała współpraca czy zlecenie o stałym zakresie?** Oba warianty. Stała współpraca (10-40 godzin miesięcznie) pasuje zespołom z ciągle działającymi funkcjami AI na produkcji. Zlecenia o stałym zakresie (migracja dostawcy, ponowne ustalenie punktu odniesienia w ewaluacji, przestrojenie promptów) pasują zespołom z konkretnym zdarzeniem. **Q: Co, gdy zdarzy się incydent na produkcji?** Klienci w stałej współpracy dostają doraźne wsparcie przy incydentach w godzinach pracy: dołączamy do rozmowy kryzysowej, pomagamy debugować, piszemy raport po incydencie. Czasy reakcji ustalamy w umowie; dyżur całodobowy to osobne uzgodnienie. **Q: Czy obsługujecie pełny DevOps i SRE?** Obsługujemy operacje specyficzne dla AI: dryf promptów, migracje modeli, procesy ewaluacji, monitoring kosztów modeli. Ogólna praca SRE (Kubernetes, infrastruktura jako kod, tradycyjne alerty) wchodzi w zakres tylko tam, gdzie styka się z funkcjami AI. **Q: Jak wyglądają migracje modeli?** Standardowe zdarzenie utrzymaniowe. Ponownie ustalamy punkt odniesienia w ewaluacji dla nowego modelu, uruchamiamy testy regresji i przenosimy prompty tam, gdzie nowy model potrzebuje innych wzorców. Mierzymy jakość, opóźnienie i koszt przed i po. Kalendarz wyznaczają zasady dostawców. Anthropic ogłasza wycofanie modelu udostępnionego publicznie co najmniej 60 dni przed jego wyłączeniem. OpenAI daje co najmniej 6 miesięcy dla modeli ogólnie dostępnych i co najmniej 3 miesiące dla wariantów wyspecjalizowanych, a modele w wersji preview mogą dostać znacznie krótszy termin. W praktyce Anthropic wycofał między październikiem 2025 a sierpniem 2026 dziewięć wersji modeli w sześciu terminach, z wyprzedzeniem od 60 do 189 dni. Jakość odpowiedzi może się zmienić także bez wycofania modelu: skuteczność GPT-4 w rozpoznawaniu liczb pierwszych spadła z 84% w marcu 2023 do 51% w czerwcu 2023 (Chen, Zaharia i Zou). **Q: Czy możecie utrzymywać kod, którego nie budowaliście?** Tak. Faza przejęcia obejmuje przeczytanie i udokumentowanie systemu. Zanim stała współpraca będzie możliwa, może być potrzebna spłata długu utrzymaniowego w osobnym zakresie. ### Powiązane - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/llm-observability - https://23minds.com/pl/uslugi/utrzymanie-i-monitorowanie-ai/optymalizacja-kosztow-llm - https://23minds.com/pl/uslugi/budowa-i-automatyzacja-z-ai/budowa-oprogramowania-z-ai ---