As long as you are not looking for something very specific, and you are not performing a sanity check of what you are matching against, the provided regular expression will match more often wrong than falsely not matching. It will even match more nonsense InChI than total number of existing ones. It is therefore not much better than the trivial catch them all:

^InChI\=1S?\/[^\s]+(\s|$)

The space (and some few others) is a character that will not be part of a correct InChI. The above will therefore match all correct InChI strings (and many more), and certainly more correct ones than the one given in the question (or in your answer).

The principle problem with the whole approach is basically given in the technical FAQ in section 5. Depending on what we are looking at, not all the layers will be present. There is not even a guarantee that a sum formula is present, as represented by the proton: InChI=1S/p+1. This one (and its relatives) is basically responsible why regex is doomed from the start, and that there is no correct regex in the first place.

If we wanted to implement only a tiny fraction of sanity control to reduce the number of mismatches, we will soon see that the whole string becomes about a page long. Let's examine the given regex a little more to actually understand what it and why it's attempt is futile.

^InChI\=1S?\/[A-Za-z0-9\.]+(\+[0-9]+)?(\/[cnpqbtmsih][A-Za-z0-9\-\+\(\)\,\/\?\;\.]+)*$

Beginning with

^  

matches the start of the string, which is not really necessary

 InChI\=1S?

matches the prefix, while leaving it open if standard or not

           \/[A-Za-z0-9\.]+(\+[0-9]+)?

matches a sum formula (even the silly ones) or anything that doesn't have a main layer and goes straight to isotopes or charges, etc.. Better would here be to make the sum formula optional, i.e. (\/[A-Za-z0-9\.]+)?

                                      (\/[cnpqbtmsih][A-Za-z0-9\-\+\(\)\,\/\?\;\.]+)*$

this is pretty much a fancy way of saying match any kind of layer, as often as you want,( or not,) in what order is just convenient, with whatever content. However, it does not match *, which it should: InChI=1S/2C2H5.Zn/c2*1-2;/h2*1H2,2H3; as given in the FAQ.

A much better approach would be to match the layers separately, to have a little control, because they have a predefined order. For example start with the connectivity 1.1 layer (\/c[0-9\-\*\;\(\)]+)?, move to the connectivity 1.2 or hydrogen layer (\/h[H0-9,\(\)\;]+)?. I am not too sure whether I caught all special characters that might be inserted. Then match on with charge (\/q(\+|\-)+[1-9]+[0-9]*)? and the proton balance \/p, the various stereochemistry layers, fixed layers, etc. There are plenty. I probably got the charge already halfway wrong, as I am not sure whether it needs ; or not.

Coming up with a correct and not too greedy regex for each layer is already a nice task, and if you can do something useful with it, good. For everything else, there is a reason that a software exists to create and parse those strings. For every other purpose the greedy match-it-all from the start should work perfectly fine. Now, InChIKeys are something very different ...