AI, Drones and Remote Inspection Under ISO/IEC 17020:2026

If your inspection body flies a drone, runs a remote inspection over video, or lets an algorithm flag defects, the 2026 edition has something to say to you that the 2012 edition did not. For the first time, ISO/IEC 17020 names technology directly and tells you what to prove. The short version: any technology you use in connection with inspections has to be validated before use, kept secure, maintained, and revalidated when it changes, and any inspection result that comes from artificial intelligence or a digital development has to be addressed in your method. This guide turns those requirements into the specific evidence an assessor will ask for, clause by clause.

Here is where most coverage of the 2026 revision falls short. It mentions that the edition “addresses AI and remote techniques” and stops there, without naming a single clause or telling you what record to keep. The requirements actually sit in three specific places: clause 6.2.9 on the technology itself, clause 7.2.5 and 7.2.6 on methods and AI-generated results, and clause 7.5 on the control of your data. Get those three right and you have covered the new technology obligations.

Why the standard added these clauses now

The technology clauses did not appear in a vacuum. Inspection has been moving onto drones, remote video and algorithmic analysis fast enough that a standard which ignored them would have been out of date on publication. The exact size of that shift is debated, but the direction is not: every major analyst forecast has drone and remote inspection growing at double digits a year.

Clause 6.2.9: validating the technology itself

Clause 6.2.9 is the heart of it. It applies whenever you use technology in connection with inspections, and the standard gives the examples directly: computers or automated equipment, data processing, artificial intelligence, augmented reality or remote inspection techniques. If any of that is in your workflow, the clause sets three obligations.

First, the technology shall be suitable and adequate for use. The note to the clause spells out how you show that: validation of calculations before use, periodic revalidation of related hardware and software, revalidation whenever changes are made to that hardware or software, and software updates implemented as required. In practice this means you cannot simply buy a defect-detection model or a drone-mapping package and trust it. You validate it against known cases before it goes live, you revalidate it on a schedule and after any change, and you keep the records.

Second, procedures shall be established and implemented for protecting the integrity and security of data. Third, the equipment, including hardware and software, shall be maintained to ensure proper functioning. Read together, 6.2.9 treats your drone, your AI tool and your remote-inspection rig the same way the standard has always treated a measuring instrument: it has to be fit for purpose, controlled, secured and looked after, with evidence at each step.

Let me be direct about the trap here. The most common gap is not failing to validate at all; it is validating once at purchase and never again. The clause asks for revalidation after changes and on a periodic basis, and AI models and software in particular change often, sometimes silently through a vendor update. If your model was revalidated the last time its version number moved, you are covered. If it has updated three times since your only validation record, you have a finding waiting.

Clauses 7.2.5 and 7.2.6: AI results and method validation

Clause 6.2.9 governs the tool. Clause 7.2 governs the method that uses it. The expanded list in 7.2.5 of what an inspection method shall address now includes three items that bear directly on technology. It names activities for which the inspector’s judgement may rely on the use of technology (7.2.5 b), it requires you to address information supplied by any other party and how the integrity and validity of that information is verified (7.2.5 e), and, most explicitly, it requires the method to address inspection results from artificial intelligence or digital developments (7.2.5 f).

That last point is the one to read carefully. If an algorithm produces a result your inspection relies on, your method has to say how that result is treated: where it informs the inspector’s judgement, where it is checked, and how a wrong output would be caught. The standard does not ban AI from inspection, and it does not let the AI make the call unexamined. It puts the result inside your documented method, where it can be controlled.

Clause 7.2.6 then requires you to validate non-standard inspection methods or procedures, including when technology is used, and to retain the records of that validation. The note confirms the scope plainly: the technology in question can be digital developments, modelling, the use of artificial intelligence or remote techniques. The standard even offers validation techniques you can use: a systematic assessment of the factors influencing the result, testing the method’s robustness by varying controlled parameters such as the inspector or the equipment, and comparing results against other validated methods. Any one or a combination of these will do, as long as the validation is appropriate to your application and the records exist.

Clause 7.5: controlling the data your technology produces

Technology produces data, and the 2026 edition adds a standalone clause, 7.5, to control it. The system you use to collect, process, record, report, store or retrieve data relevant to inspection activities shall be validated. Whenever there are changes, including changes to your software configuration or modifications to commercial off-the-shelf software, those changes shall be authorized, documented and validated before implementation. There is a sensible carve-out in the note: commercial off-the-shelf software in general use within its designed application range can be considered sufficiently validated, so you are not expected to validate your word processor.

Clause 7.5.2 then sets the protection requirements. Technical data and inspection records shall be safeguarded against unauthorized access, tampering and loss, maintained in a way that ensures their integrity and security, and shall include information on system failures and the appropriate immediate and corrective actions. That last requirement is easy to miss: you are expected to keep a record of when a system failed and what you did about it. For a body running drones, cloud platforms and inspection apps, that means access control, backups, and a log of outages and their fixes, not just a privacy statement.

The validation-evidence table

Pull the three clauses together and you get a simple map: for each kind of technology you use, here is the clause that governs it and the evidence an assessor expects to see. This is the table to keep next to your method documents.

Remote and AI do not move the responsibility

One principle sits underneath all of this and it is worth stating plainly. Technology changes how you inspect; it does not change who is accountable for the result. The inspection report or certificate shall be traceable to the inspector who performed the inspection (7.6.4), and where any part of the inspection is externally provided, the responsibility for the inspection results and the determination of conformity remains with the inspection body (6.3.5). A remote inspection is still your inspection, an AI-flagged defect is still your finding, and a drone survey your inspector relied on is still your judgement to defend.

That has two practical consequences. Your inspectors still need the competence to interpret what the technology produces (Clause 6.1), because the standard expects professional judgement, not blind acceptance of an output. And where information comes from another party, including the client, your method has to say how its integrity and validity are verified (7.2.5 e), so a client-supplied drone dataset is not waved through unchecked. Used this way, technology is an asset the standard fully accommodates. Treated as a black box that makes the decision for you, it is the fastest route to a nonconformity.

Where to take this next

The technology clauses sit inside the wider standard, so read them alongside the rest: the clause-by-clause requirements guide walks Clauses 4 to 8 and Annex A in order. If you are adding or formalising this technology as part of moving to the 2026 edition, fit it into the transition plan and its deadlines. The clause text itself is in the standard on the ISO catalogue page, and ANAB’s summary of the 2026 changes is on the ANSI National Accreditation Board blog.

To build the validation records, data-control procedures and method documents these clauses ask for, the ISO/IEC 17020:2026 Documentation Kit includes the technology and data-control templates already structured to the 2026 clauses, so you adapt them to your tools rather than writing them from scratch.